solution guide for video conferencing rel1dot2€¦ · solutions guide for: video conferencing...

Solutions Guide For

Video Conferencing Systems

Version: 1.2

Release Version: 1.2 January 19, 2005

Solutions Guide for: Video Conferencing Systems Version 1.2 January/ 2005

Nortel Networks 1

Abstract This document outlines a Video Conferencing solution based on the interworking between the MCS 5100 and the Polycom Video Conferencing systems. Revision Control No Date Version Remarks

1 10/04/04 DRAFT .1 Initial DRAFT release for comment

2 10/07/04 DRAFT .2 Removed Use Case Appendix. Added Traffic Engineering Section. Numerous Spelling and grammar corrections.

3 10/20/04 DRAFT .3 Compiled input from all document contributors.

4 10/21/04 DRAFT .4 Release to wider audience for feedback.

5 11/02/04 Release 1.0 Incorporate feedback from reviewers. Formatting, spelling and grammar corrections.

6 11/17/04 Release 1.1 Incorporate feedback from reviewers. Formatting, spelling and grammar corrections.

7 01/19/05 Release 1.2 Added ANSI T1.522 Multimedia Reference Table 3 and Table 4

Copyright © 2004 Nortel Networks All rights reserved. March 2004 The information in this document is subject to change without notice. The statements, configurations, technical data, and recommendations in this document are believed to be accurate and reliable, but are presented without express or implied warranty. Users must take full responsibility for their applications of any products specified in this document. The information in this document is proprietary to Nortel Networks Inc. The software described in this document is furnished under a license agreement and may be used only in accordance with the terms of that license. Trademarks Nortel Networks, the Nortel Networks logo, the Globemark, Unified Networks, and PASSPORT are trademarks of Nortel Networks. Adobe and Acrobat Reader are trademarks of Adobe Systems Incorporate. All other Trademarks are the property of their respective owners.


Nortel Networks 2

Table of Contents

1. OVERVIEW......................................................................................................................................... 7 1.1 SOLUTION DESCRIPTION ................................................................................................................ 7 1.2 SOLUTION CAPABILITIES ............................................................................................................... 7 1.3 SOLUTION BENEFITS...................................................................................................................... 7

2. EXISTING NETWORK ENVIRONMENT...................................................................................... 8 2.1 TYPICAL ENTERPRISE TOPOLOGY.................................................................................................. 9 2.2 NETWORK CONSIDERATIONS ....................................................................................................... 10

3. CONFERENCING SOLUTIONS .................................................................................................... 10 3.1.1 Polycom Room Systems .......................................................................................................... 10

3.1.1.1 Software Requirements ................................................................................................................. 11 3.1.1.2 Hardware Requirements................................................................................................................ 11 3.1.1.3 Features......................................................................................................................................... 11

3.1.2 Polycom Desktop Systems....................................................................................................... 11 3.1.2.1 Software Requirements ................................................................................................................. 12 3.1.2.2 Hardware Requirements................................................................................................................ 12 3.1.2.3 Features......................................................................................................................................... 12

3.1.3 MCS Video Conferencing ....................................................................................................... 12 3.1.3.1 Software Requirements ................................................................................................................. 12 3.1.3.2 Hardware Requirements................................................................................................................ 13 3.1.3.3 Features......................................................................................................................................... 13

3.1.4 Multipoint Video Conferencing infrastructure ....................................................................... 13 3.1.4.1 Software Requirements ................................................................................................................. 15 3.1.4.2 Hardware Requirements................................................................................................................ 15 3.1.4.3 Features......................................................................................................................................... 15

4. CONFERENCING BASICS AND BENEFITS............................................................................... 16 4.1 GETTING THE MOST OUT OF YOUR SYSTEM.................................................................................. 16 4.2 POINT-TO-POINT CONFERENCING ................................................................................................ 17 4.3 MULTI-PARTY CONFERENCING.................................................................................................... 17 4.4 COLLABORATION......................................................................................................................... 17 4.5 STANDARDS................................................................................................................................. 18 4.6 ENCODING AND CODECS ........................................................................................................... 19

5. SOLUTION TOPOLOGY ................................................................................................................ 21 5.1.1 Call flow examples.................................................................................................................. 22

5.1.1.1 MCS Point-to-Point Call ............................................................................................................... 22 5.1.1.2 MCS Multipoint Call..................................................................................................................... 22 5.1.1.3 VSX Point-to-Point Call ............................................................................................................... 22 5.1.1.4 VSX Multipoint Call ..................................................................................................................... 23 5.1.1.5 MCS to VSX Call ......................................................................................................................... 23 5.1.1.6 MCS and VSX Multipoint Call ..................................................................................................... 23

5.2 INTEROPERABILITY...................................................................................................................... 24 5.3 PERFORMANCE ............................................................................................................................ 24

5.3.1 QoS ......................................................................................................................................... 25 5.4 TRAFFIC ENGINEERING ................................................................................................................ 26 5.5 SCALABILITY ............................................................................................................................... 28

5.5.1 Multipoint Gateway Controller .............................................................................................. 28 5.5.2 MCS 5100 ............................................................................................................................... 28

5.6 RELIABILITY ................................................................................................................................ 28 5.7 SECURITY .................................................................................................................................... 30

5.7.1 NAT & Firewall traversal Requirements................................................................................ 30 5.7.1.1 Application Level Gateway (ALG)............................................................................................... 31 5.7.1.2 The MCP RTP Media Portal ......................................................................................................... 32


Nortel Networks 3

5.8 DEPLOYMENT CONSIDERATIONS ................................................................................................. 33 5.8.1 Videoconference Room Design............................................................................................... 33 5.8.2 Seating Recommendations ...................................................................................................... 33 5.8.3 Location & Environment ........................................................................................................ 34

5.8.3.1 Wall Construction ......................................................................................................................... 35 5.8.3.2 Ceiling Construction ..................................................................................................................... 35 5.8.3.3 Floor Covering .............................................................................................................................. 35 5.8.3.4 Lighting......................................................................................................................................... 35 5.8.3.5 Heating Ventilation Air Conditioning (HVAC) System................................................................ 36 5.8.3.6 Door .............................................................................................................................................. 36 5.8.3.7 AC Power Circuits ........................................................................................................................ 36 5.8.3.8 Cable ways .................................................................................................................................... 36

5.9 CONFIGURATION GUIDELINES ..................................................................................................... 37 5.9.1 Step 1: MGC as Trusted Node. .............................................................................................. 38 5.9.2 Step 2: Provisioning MGC as Gateway.................................................................................. 39

5.9.2.1 Add Gateway Route ...................................................................................................................... 41 5.9.2.2 Add Trunk Groups ........................................................................................................................ 42

5.9.3 Step 3: Provisioning Telephony Routes for the MGC Gateway............................................. 44 5.9.4 Provisioning Polycom VSX endpoints .................................................................................... 47

6. ACCEPTANCE TESTING............................................................................................................... 48 7. MIGRATION..................................................................................................................................... 48 8. SUPPORT SERVICES...................................................................................................................... 49 9. TRAINING......................................................................................................................................... 49 10. TECHNICAL SUPPORT ............................................................................................................. 49 11. APPENDIX A – FEATURE MATRIX........................................................................................ 50 12. APPENDIX B – ACRONYMS ..................................................................................................... 53


Nortel Networks 4

Tables & Figures Figure 1: Reference Network........................................................................................................... 9 Figure 2: Video Conferencing Reference Solution........................................................................ 21 Figure 3 MCS Point-to-Point Call .................................................................................................. 22 Figure 4 MCS Multipoint Call......................................................................................................... 22 Figure 5 VSX Point-to-Point Call ................................................................................................... 22 Figure 6 VSX Multipoint Call.......................................................................................................... 23 Figure 7 MCS to VSX Call ............................................................................................................. 23 Figure 8 MCS and VSX Multipoint Call ......................................................................................... 23 Figure 9 H.320/H.323/SIP Interoperation ...................................................................................... 24 Figure 10 Ethernet & IP Overhead ................................................................................................ 27 Figure 11 MCS Multi-chassis Hunt Configuration ......................................................................... 30 Figure 12 Small Room - Five persons........................................................................................... 33 Figure 13 Medium Room - Nine Persons ...................................................................................... 34 Figure 14 Large Room - Thirteen Persons.................................................................................... 34 Figure 15 Locking the component ................................................................................................. 38 Figure 16 Component Modify Window .......................................................................................... 39 Figure 17 Add Gateway Window................................................................................................... 40 Figure 18 Gateway Window .......................................................................................................... 40 Figure 19 Update Gateway............................................................................................................ 41 Figure 20 Gateway Routes............................................................................................................ 41 Figure 21 Add Route Entries ......................................................................................................... 42 Figure 22 Trunk Groups ................................................................................................................ 42 Figure 23 Trunkgroup Provisioning ............................................................................................... 43 Figure 24 TrunkGroup Parameters................................................................................................ 43 Figure 25 Reorder Trunk Groups .................................................................................................. 44 Figure 26 List Telephony Routes................................................................................................... 44 Figure 27 Modify Telephony Route ............................................................................................... 45 Figure 28 Route List ...................................................................................................................... 46 Figure 29 Modify Route List........................................................................................................... 46 Figure 30 Modify Route List Parameters....................................................................................... 47

Table 1 MGC Models..................................................................................................................... 14 Table 2 QoS Recommendations ................................................................................................... 25 Table 3 Audio/Video Skew ............................................................................................................ 26 Table 4 Maximum One Way Delay................................................................................................ 26 Table 5 Seating Capacity and Table Recommendation................................................................ 33


Nortel Networks 5

Table 6 Feature Matrix .................................................................................................................. 52


Nortel Networks 6

Icons Used in this Paper

The following Icons are used in the diagrams throughout this paper.

Document Contributors

Evan Black IS Video & Audio Conferencing (613) 765-6176 [email protected]

Willis Chun Solutions Ready (972) 684-2484 [email protected]

Dean Harris MCS 5100 (919) 997-0417 [email protected]

Ed Koehler Jr. Enterprise Portfolio Architecture (585) 654-2323 [email protected]

Zia Mansoor IS New Technology & NPI (905) 863-1856 [email protected]

Matt Trainor Solutions Ready (613) 765-5008 [email protected]

Laurence Tyler Solutions Ready (613) 765-2418 [email protected]

L2/L3 switch/router

Legacy router

L2 switch

Generic Server

Desktop PC

Firewall

Desktop PC w Multimedia

i200x Hardware Phone

MCS 5100

Internet

Polycom MGC 100/50/25

MCS Client

Polycom VSX 7000

Polycom IP 500

Polycom H.320 EndpointH.320 Endpoint


Nortel Networks 7

1. Overview This document describes Nortel’s Enterprise Video Conferencing Solutions using Nortel’s Multimedia Communications Server, the MCS 5100, MCS Multimedia Clients and 3rd party Video Components. It provides a guide to the benefits, capabilities, deployment, engineering and configuration and of the video conferencing solution offer. This document outlines the solution in conjunction with 3rd party video components from Polycom.

1.1 Solution Description The Nortel MCS / Polycom Solution leverages the strengths of both vendors to create a simpler, more powerful and easy to use video conferencing solution. The MCS 5100 is a SIP based session controller that enables calls to easily be established and managed between SIP clients, and is a key component to providing an integrated communication environment. Polycom’s SIP based video components compliment this solution by providing user and room videoconferencing endpoints (VSX family), and a family of conferencing bridge platforms (MGC) that provide multipoint bridging plus interfaces to legacy (non-SIP) videoconferencing systems.

1.2 Solution Capabilities An integrated MCS 5100 and Polycom solution delivers a seamless suite of applications that leverage the enterprise IP infrastructure. High quality room systems integrated with PC based desktop systems ensures investment protection and provides the following capabilities;

o Video conferencing

o Audio conferencing

o Collaboration

o Whiteboard, clip board and file exchange

o Dynamic presence

As the solution matures features and capabilities increase. A summary of the available features and capabilities can be found in Appendix A at the end of this document.

1.3 Solution Benefits The use of Video Conferencing (VC) in the enterprise is becoming much more “main stream” with the development of SIP based solutions that use the IP infrastructure as the foundation for communications. The days of problematic ISDN connections have largely been eliminated with the dependency for connectivity moving to a more stable, and easier to manage IP network. Eliminating the need for ISDN, standards-based SIP connectivity, and lowering the cost while increasing the quality of the video/audio systems are all contributing factors to the increased use of VC systems. With the MCS Multimedia Client, setting up impromptu VC sessions between two parties is easily accomplished. With a complete SIP environment (MGC, VSX 7000 and MCS), activating an MCS Multimedia client VC session to a Polycom room system will be just as


Nortel Networks 8

easy. A simple and seamless call establishment process is essential to successful VC deployment and user acceptance. The benefits of a SIP based VC solution are many with some of them listed below.

o Reduce cost

o Support mobile and telecommuting employees, while simultaneously providing anytime/anywhere access. Save as much as 40 percent over traditional alternatives for telecommuters. There's no need for a second phone line, no separate voice mail, and greatly reduced use of calling cards. With MCS 5100, employees can access advanced services from cell phones, PCs, SIP terminals, and wireless devices.

o Meet Me Conferencing

o Audio and video conferencing can be easy and inexpensive, without requiring a specialized dial plan or dedicated video facilities. Eliminate outsourced conferencing costs. Make multimedia services-such as virtual tours, live training demos, Instant Messaging, and on-demand videoconferencing-as easy as placing a voice call.

o Productivity and collaboration

o Save employees time, simplify the sharing of information and make critical decisions faster with collaborative services, such as instant messaging, chat, automatic presence and personalized call handling. Studies have found up to 8% time savings with single interface access to multimedia applications. Leverage dynamic presence to reach key resources immediately.

o Simplify operations

o Eliminate communications barriers that inhibit doing business through simplified operations, network-wide applications, native conferencing and access from multiple clients and devices.

o Investment protection

o Keep existing desktop, access integrated multimedia services and evolve those services as the network evolves. Reduce capital expenditures, training and implementation costs.

2. Existing Network Environment Videoconferencing systems are typically added to an existing enterprise infrastructure, hence an understanding of the existing environment is essential to a successful Video Conferencing solution implementation. A typical enterprise IP network is difficult to categorize and there are many factors that influence the type of network that is deployed. Enterprise networks can be grouped into “bins” using the number of hosts per network as a guide, since the number of hosts is indicative of both network complexity and size. These bins are (1) Very Small Enterprise (Less than 100 Hosts), (2) Small Enterprise (Up to 1000 Hosts), (3) Medium Enterprise (Up to 10,000 Hosts) and (4) Large Enterprise (Over 10,000 Hosts).


Nortel Networks 9

When looking at the networks in detail, each enterprise has unique requirements but generally they support multiple sites, have a headquarters (or central) site, have Internet access and have a common set of applications that the network must support. The enterprise that makes use of VC systems will, no doubt, fall into the category of a Medium to Large Enterprise. This also holds true for the type of enterprise that would deploy a MCS solution to meet their VoIP and collaboration needs. This section documents a Large Enterprise network reference configuration that will be used in following sections to demonstrate a typical VC deployment.

2.1 Typical Enterprise Topology Shown below is a diagram representing a typical Large Enterprise IP network that will be used as a reference for deploying a mixed MCS/Polycom Video Conferencing solution.

Figure 1: Reference Network

At the center of the diagram is the Head Office location and includes three separate buildings spread over a Head Quarters (HQ) campus. The buildings in the campus are connected by enterprise owned fiber and the fiber terminates on a L2/3 routing switch in each building. The core of the enterprise IP network is supported by L2/3 routing switches that are connected together in a mesh arrangement for redundancy purposes. The users connect to wiring closet switches that are in turn connected to the core L2/3 routing switch. The Metro Sites and Remote sites are all connected back to the HQ site in a Hub-and-Spoke configuration. Two Metro sites are shown to the left of the HQ Campus and these sites are connected back to HQ by a Metro Ethernet service. Metro Site 1 is connected back to the HQ using a L2 Ethernet extension. Metro Site 2 terminates the Ethernet connection on a L3 Router interface. To the right of the HQ campus are two remote office locations that have an ATM WAN connection back to HQ.

L2 / L3 Core

L2 / L3 Core

DMZ

WWW DNS SMTP FTP

LARGE HQ

CAMPUS

FW, NAT

DHCP, DNS

Building 1 Building 2

DHCP, DNS

DHCP, DNS

Metro Site 1

Metro Site 2

DHCP, DNS

NOC

Remote Office 1

Remote Office 2

MetroMetro

WANWAN


Nortel Networks 10

All sites gain access to the Internet through the Firewall/Internet connection at the HQ site.

2.2 Network Considerations The above network is typical of a network that has been deployed to support data application, with little regard for resiliency and redundancy. The Hub-and-Spoke topology provides no alternate paths in case of a facility failure and the network elements in the remote offices represent single points of failure. The core campus network can be designed using a meshed core and can easily provide a highly available IP core, although these details are not shown. Although this is a model that has served enterprises well for their data needs, changes are needed to improved reliability to meet the QoE expectation for multimedia communications. Also needed is a solid QoS strategy and implementation. Both these additional network considerations will be discussed in Section 5, as the multimedia services are added to the existing network.

3. Conferencing Solutions A Video Conference system facilitates communication with remote locations via audio and video with supplemental high resolution video graphics optionally available. This communication is carried out over standard ISDN and IP links. To reduce the required bandwidth the analog video and audio signals are digitized and compressed before transmission. The basic required components in each Video Conference room are a microphone, a camera, a codec, an audio system and a visual display device (i.e. television monitor, plasma display, video projector).

** NOTE **

For a complete list of supported features and any associated caveats, refer to Appendix A – Feature Matrix.

3.1.1 Polycom Room Systems Polycom supports a range of systems to meet the requirements for various room sizes and implementations. These systems are referred to as the VSX family and are available in several models. All models support IP connectivity as a base for communication and with ISDN support available as an option.

The VSX 8000 series is intended for large “high end” installations, ideal for integration into a customized installation or refitting an existing boardroom. It features

o Expansion of the VSX architecture in a rack-mount form factor. o Siren 14 Stereo projected from left and right speakers o Add multiple voice and video participants to the same conference o Integrated People+Content for streamlined presentations. o Professional grade connectors make adding audio and video peripherals a

breeze.


Nortel Networks 11

The VSX 8800 model is a high performance system that includes Polycom’s PowerCam Plus for voice activated tracking to presets and built in multipoint capability. The VSX 8400 model includes Polycom’s fast quiet PowerCam for simple operation and is ideal for an instructor or presenter environment. Either of these models can be paired with Polycom’s Executive Collection dual 50 inch plasma display solution. Common to both models are integrated People+Content high resolution graphics capabilities, AES encryption, advanced video and high quality audio support and extensive API control interface support.

The VSX 7000 series offers much of the same functionality as the VSX 8000 series in a set top package with an integrated system main camera. It is intended for small to medium conference rooms. High resolution People+Content is supported via an external Visual Concert interface and XGA/SVGA/VGA second monitor adapter. Wide band audio is supported with an integral subwoofer and sound can be ported through the display monitor speaker system or an internal speaker. Like the VSX 8000 series, these units also support AES encryption, advanced video and high quality audio.

The V 500 workgroup system is a compact solution with integrated camera and microphones. It is intended for small conference rooms or offices. It affords a simple, easily installed solution which interoperates with the other systems. The unit installs on top of the display monitor and uses the monitor’s built in sound system.

3.1.1.1 Software Requirements

Require software version 7.0 or higher for SIP interoperability.

3.1.1.2 Hardware Requirements

All systems are self contained packages which include microphones, hand-held remote control interfaces similar to television remote controls, cameras (except for the VSX 8000 which is intended for custom installations) and cabling.

Additional requirements are display monitors. These can be standard televisions with video/audio inputs, LCD or Plasma displays or video projectors.

3.1.1.3 Features

o All systems are compatible with the ITU H.320 and H.323 standards as well as the IETF SIP protocol.

o Audio Algorithms G711, G722, G722.1, G728 G729A, Polycom Siren 14

o Video Algorithms H.261, H.263, H.264, ITU 60-fps full screen - ProMotion

o Encryption 128 bit Advanced Encryption Standard (AES)

3.1.2 Polycom Desktop Systems Polycom’s desktop solution is the VSX 3000. It is a self contained conferencing system with integrated display, camera, microphone and speakers. It also functions as an SXGA computer display for the desk top PC. It can also receive high resolution People+Content images.


Nortel Networks 12


Require software version 7.0 or higher for SIP interoperability.


None, unit is self contained package which doubles as an SXGA PC display

3.1.2.3 Features

o Compatible with the ITU H.320 and H.323 standards as well as the IETF SIP protocol.

o Audio Algorithms G711, G722, G722.1, G728 G729A, Polycom Siren 14

o Video Algorithms H.261, H.263, H.264, ITU 60-fps full screen - ProMotion

o Encryption 128 bit Advanced Encryption Standard (AES)

o IP and ISDN network capable

o Dual Monitor Emulation

3.1.3 MCS Video Conferencing MCS 5100 Release 3 provides support for SIP-based point to point as well as multipoint video conferencing. The only Nortel video endpoint supported is the Multimedia PC Client (MMPCC). The MMPCC is a Microsoft Windows software package that installs on standard Windows operating system environments. Early versions of the MCS multimedia PC client were based on JAVA and only supported the DivX video codec. The later version of the MMPCC introduced in Release 3 adds support for the open industry standard H.263 video codec in addition to the default DiVX video codec. Support for the H.263 video codec is instrumental to interoperability with both Polycom and other industry vendor end points. The MCS multimedia client will support most USB RGB based video cameras that are supported as plug & play by Windows.

The MMPCC can work in a stand alone fashion or it can work in tandem with an i200x IP phone in a PC client-set mode. The stand-alone configuration facilitates access for remote or traveling users where the audio is provided through the PC audio device. In the PC client-set mode, all audio is routed to the i200x IP set while video and other collaborative features are supported on the PC client interface. This enables the use of VPN software, such as Nortel Contivity, to establish a tunneled IP connection to the enterprise network.

Multiport Video Conferencing was also introduced in MCS 5100 Release 3. This feature adds desktop video conferencing to the ad-hoc and meet-me audio conferencing services on the Media Application Server (MAS). This feature supports up to 100 simultaneous video participants (streams) for each server. This feature is based on voice activated video switching whereby the video for an active speaker in a conference is tracked and streamed to the other participants. Audio-only clients can participate in video conferences although they cannot send or receive video.

The only video codec supported by the Multiport Video Conferencing feature is DivX. H.263 is not supported. This means that only MMPCC Multimedia Web Client users may participate in a Multiport Video Conferencing conference. If a Polycom device using SIP/H.263 dials into a Multiport Video conferencing call, only the audio portion of the call will be connected.


MCS 5100 Release 3 (FF)


Nortel Networks 13

In addition to the standard software requirements for the MCS 5100 as outlined in the NTPs, interoperability with Polycom devices requires the later version (also referred to as the C++ version) of the Multimedia PC Client introduced in MCS 5100 Release 3. This client adds support for the H.263 video codec.

Availability of the H.263 video codec is controlled through Service Package provisioning. H.263 services are only enabled if the user service package “H.263 Video Enabled” parameter is set to ‘Y’.


No additional hardware is required at either the client or server level of the MCS 5100 to enable Polycom interworking. However, preliminary tests have determined that use of the minimum recommended hardware configuration (500Mhz CPU, 256M memory) on the Multimedia PC client has resulted in unsatisfactory video performance with either the 192kbps (medium bandwidth) or 512kbps (high bandwidth) settings when using the H.263 video codec. Generally speaking, this should not be a serious concern since most business desktop systems exceed the minimum PC requirements.

3.1.3.3 Features

The MCS 5100 is designed to be implemented with a smooth migration path. You can introduce multimedia communications and new productivity tools at a lower cost and without network disruption. MCS 5100 is easily introduced into multi-vendor PBX or VoIP networks, through features like converged desktop where existing desktops and phones can be retained while adding leading-edge SIP-based multimedia services. It provides a simple, easy-to-use interface that works on a range of devices that can be centrally engineered and administered. Additionally, it enables ubiquitous access to telephony and multimedia applications irrespective of where the workplace is - office, home, or remote business travel.

o Compatible with IETF SIP protocol

o Audio Algorithms G711, G729A

o Video Algorithms DivX (MPEG 4), H.263

o SIP RFC 2833 DTMF support

o Global IP Sound (GIPS) support

o Support for telephony features: Call, answer, hold/unhold, transfer, conference, park, reject, forward.

3.1.4 Multipoint Video Conferencing infrastructure The Multimedia Communication Server 5100 supports SIP and H.323 protocols. Currently the H.323 gatekeeper supports audio sessions only, Video Conferencing support is provided by the Polycom MGC gateway/MCU.

Polycom’s MGC-50 and MGC-100 deliver high levels of reliable multipoint and gateway conferencing support and unique capabilities to flexibly build conferencing solutions, regardless of audio or video endpoint or network connection.

Low to high end scalability, the industry’s best transcoding and the full resource sharing architecture of the MGC-50 and MGC-100 makes it easy to transition from switched to packet based service support.


Nortel Networks 14

VideoPlus™ in MGC-50 or MGC-100 configurations support ISDN and/or IP video (both H.323 and SIP) multipoint and gateway conferences. VoicePlus configurations can support PSTN and/or VoIP. Unified Conferencing configurations enables support for voice and Video Conferencing over any network. Polycom’s MGC-50 and MGC-100 can be configured to support revolutionary features such as Click&View™ and key pad conference management control in an audio, video or unified conference with integrated video, voice, data and Web capabilities. Polycom’s MGC-50 and MGC-100 platforms support scalable conferencing and gateway solutions, deliver proven reliability and ease of support. The 8 slot MGC-50 can be used in either a distributed or centralized deployment of conferencing and gateway services. The 16 slot MGC-100 with twice the scalable capacity of the MGC-50 and redundant powers supplies meets the requirements for a centralized service requiring support for a large number of ports, features and multiple network connections, dedicated, switched and packet.

The MGC-25 platform delivers feature-rich, economical, easy-to-use multipoint audio, video, and gateway conferencing. The MGC-25 provides high-value conferencing in a plug-and-play platform with preset configurations for unified, audio, video, and gateway conferencing. Because the MGC-25 takes advantage of the same software as the MGC-50 and MGC-100, the MGC-25 includes unique features like interactive keypad control (IVR/DTMF) for audio and Video Conferencing, and provides unmatched audio and video quality.

MGC-25 MGC-50 MGC-100

Target

Environment

Small/Medium/Large Enterprises

Medium/Large

Enterprises

Medium/Large Enterprises

Service Providers

Type of Network

Environment

Distributed Distributed &

Centralized

Centralized

Capacity Range for

IP, ISDN, VoIP, PSTN

3 - 24 8 - 480 8 - 860

Resource

Redundancy

- Yes Yes

Power Redundancy - - Yes

Hot Swappable - Yes Yes

Expansion Slots - Yes 8 slots Yes 16 slots

Configurations Preset Flexible Flexible

Table 1 MGC Models

The MGC-25 provides flexibility. End users can use a single number per conference for ad hoc conferencing, and they can choose to schedule their conferences from any MGC management and scheduling application.


Nortel Networks 15

With integrated video, audio, data, and Web capabilities, the Polycom Office is the only solution that offers you an easy way to connect, conference, and collaborate any way you want. By offering 10 different configurations, the MGC-25 can support multiple types of applications and networks including gateway, full featured, multipoint voice and Video Conferencing or both with Unified Conferencing.


Polycom MGC Software version 7 is required for SIP support.


Standard MGC hardware configurations are applicable.

The SIP operational functionality is supported on the IP48 LAN interface.

3.1.4.3 Features

o Scalable MGC 50 and 100 platforms

o Supports Unified Conferencing, Polycom VideoPlus, Polycom VoicePlus and Gateway products

o Supports multiple networks: IP and ISDN video, PSTN and VoIP audio

o Supports highest quality audio and video standards

o All platforms use the same management and scheduling applications


Nortel Networks 16

4. Conferencing Basics and Benefits Video Conferencing is changing the way companies do business. It facilitates a face-to-face meeting environment across borders, clearing the way for efficient and effective communication and collaborative decision making both within and between organizations. It is proving to be an effective form of communication with distinct benefits. Today, more than ever, it is proving to be an extremely powerful business tool, transforming day-to-day business operations by helping to increase effectiveness, maximize resources, and optimize productivity. Video Conferencing technology has progressed beyond the days of jerky Video Conferences resembling B-grade, out-of-synch foreign films. Sophisticated call management features and new video handling algorithms have made the collaborative videoconferencing experience more pleasurable and natural. Some of the distinct benefits of Video Conferencing:

o lets you be multiple places at the same time which translates to more meetings o allows for faster decision making and time to market o you can have more frequent contact with team members and colleagues,

partners, suppliers, and customers without having to leave the office o provides increased employee safety since travel involves some risk o allows for more disciplined, productive meetings o it allows for ad hoc meetings letting you discuss urgent matters and take

immediate decisions o avoided travel costs o reduced fatigue since business travel is frequently a tiring experience o by letting you save time, resources, and money, it improves the effectiveness of

your working day and your quality of life o sets your company apart from your competition

There are five essential components that compromise a Video Conferencing system: a camera, microphone, display system, audio system, and codec. The camera and microphone capture the image and sound at one location. The codec converts the video and audio into a digital signal and compresses it before sending it out over the network. At the other end, the codec decompresses the signal and feeds the picture to a monitor and the sound to an audio speaker.

4.1 Getting the most out of your System Certainly the growth potential for a multimedia Video Conferencing system is an important consideration, but just as critical is whether the system is powerful enough to provide the functionality you need now. The inherent power of the system’s codec (coder/decoder) will dictate the performance of a system. Many codecs rely on the horsepower of the PC’s CPU and actually assign conferencing tasks to the CPU. Although many CPUs are quite powerful in their own right, burdening them with conferencing tasks will only slow down other PC applications. Anyone who has struggled with an unresponsive network server knows how aggravating a slow application can be.

Video input and output flexibility will also affect a conferencing system’s usefulness. Besides camera inputs, users may want to input images from video cassette tapes or video caches. In addition, some conferences are more productive when the live video feed is output not to the PC monitor, but to another device such as an external television


Nortel Networks 17

or LCD/DLP projector. This frees the PC monitor for sharing data applications. Some multimedia conferencing systems are capable of outputting an NTSC-composite video signal, which can be switched directly from the PC to an external television.

4.2 Point-to-Point Conferencing Point-to-point Video Conferences are just that, a Video Conference between two video endpoints. At the highest level, a Video Conferencing system consists of a number of video terminals or endpoints interconnected by means of a communication network. Full duplex communication channels are used to create a real-time interactive environment between remote sites, here, two sites. The video endpoints can vary greatly in complexity, ranging from a large Video Conferencing room system down to a desktop Video Conferencing system running on a PC.

4.3 Multi-Party Conferencing Although point-to-point Video Conferences are important in communications, multipoint video connections have been found to be even more important. Multipoint or multi-party Video Conferencing permits a large number of video terminals to simultaneously participate in a Video Conference. Multipoint video connections are accomplished by each video endpoint connecting to a multipoint control unit or MCU.

4.4 Collaboration Video imaging is critical during the early stages of collaboration, but as the process continues, video communication recedes in importance as audio and data applications carry the communication load. For example, when a project team is first formed, team members need to get to know each other and this involves seeing what the others on the team look like. But as team members become comfortable with each other, verbal communication emerges as the most important medium. Video provides secondary visual clues.

Much of the information exchanged during a collaborative meeting will be communicated verbally. Decisions will be reached, responsibilities assigned, and actions taken on the basis of the spoken word. As a result, call management capabilities like directory dialing, call logs, powerful directory management facilities, and visual voice mail processing can have a palpable effect on the productivity of a group. In addition, systems that require the use of headsets or ear slugs often impede audio communication rather than improve productivity.

Once the work of a group has reached a certain point, the amount of information that must be shared often exceeds the effective limits of verbal communication. Data communication becomes critical at this point. Data applications, such as shared spreadsheets, interactive white boards, electronic slide presentations, and high-speed file transfer, facilitate the sharing of large amounts of data.

Considering the dynamics of collaboration will help establish priorities and understand user requirements when deploying Video Conferencing systems.


Nortel Networks 18

4.5 Standards Collaborative video communications has a way of snowballing. Once an individual or a group begins using it, others soon follow. As use increases, pressure builds to expand the collaborative Video Conferencing systems or to increase the number of systems available. By implementing systems that conform to industry standards, you are assured the systems you purchase today can be efficiently expanded in the future.

One of the key protocols that enables multimedia communication is the Session Initiation Protocol (SIP). SIP allows multimedia session establishment between different end devices regardless of where they are physically located. It is a signaling protocol defined in RFC 3261for Internet conferencing, telephony, presence, events notification and instant messaging. SIP was born from the need to provide standardization for communications between collaborating universities and was largely driven to adoption by Columbia University. The Columbia University web site (http://www.cs.columbia.edu/sip/) is an excellent resource for tutorials, papers, presentations and other valuable SIP information.

SIP enables the following multimedia functions:

o Name translation and user location o Allows users to find each other on the network without needing to know

address or physical location information

o Media Negotiation o Enables all participants to agree on a common media and technology –

including voice, video, audio, Instant Messaging, and applications for information exchange

o Session Management o Manages the adding, dropping, transferring of participants

o Feature Changes o Enables changing the media used in a session while the session is still in

progress

Nortel fully endorses the adherence to industry standards and this holds true for SIP support and development. It is crucial to successful vendor interoperability, as will happen in most converged networks, that this dedication to standards be unwavering. Two papers available from Nortel that convey the corporate position regarding SIP can be found by following the links below.

http://www.nortelnetworks.com/products/01/succession/es/succession_csemx/doclib/nn109080-081204.pdf

http://www.nortelnetworks.com/products/01/succession/es/succession_csemx/doclib/nn106700-060204.pdf

Since the mid-1990’s, the International Telecommunications Union (ITU) has defined worldwide standards for Video Conferencing. These standards have been written to guarantee compatibility between different manufacturers’ Video Conferencing systems. When choosing your system, it is very important to ensure that it complies with these standards and does not offer only a proprietary method of communication. Proprietary systems will only connect with another of the same design. Investing in Video Conferencing systems that meet worldwide standards will ensure that:


Nortel Networks 19

o Video Conferencing systems are equipped with the latest technology o Investment will not become obsolete within a short period of time o Video Conferencing system provides improved picture quality at all data

transmission rates o Video Conferencing system will communicate freely with all other standards

based systems.

The umbrella industry standard for multimedia conferencing, H.320, was defined in 1990 by the International Telecommunications Union (ITU). In theory, audio and video equipment that is H.320-compliant will function with any other vendor’s H.320 equipment. H.320 defines most of the basic processes involved in multimedia conferencing, such as video compression, decompression and digitization, as well as high-quality audio compression and transmission. Even though an H.320 channel includes a data link for shared data processing applications, H.320 does not establish the protocol used on this data link. For this reason, you can not be assured that data applications on H.320 systems from different vendors will interoperate.

Another ITU standard known as T.120 establishes the data application protocol. When an application is said to be T.120-compliant, it can be shared by meeting participants at either end of a two-way multimedia conference or by several groups of participants in a multipoint conference.

Another ITU conferencing standard is H.323. The H.323 standard encompasses audio, video, and data communications across packet-based networks – LAN, Intranet, Extranet, and Internet. The H.323 standard was developed to allow multimedia products and applications from multiple vendors to interoperate. Compatibility is the key concern for vendors and end users for LAN-based products.

In 1996 the ITU approved the H.323 specification. The standard is broad in scope and includes standalone devices and embedded personal computer technology as well as point-to-point and multipoint conferences. The standard addresses issues such as call and session control, multimedia and bandwidth management for point-to-point and multipoint conferences.

The main standards for Video Conferencing are: H.261; H.263; H.264; H.221; H.242; H.230; H.231; H.243; H.224; H.281; H.245; H.225; G.711; G.722; G.722.1; G.722.2; G.728; G.729;

4.6 Encoding and CODECS As stated in the previous section, the main umbrella industry standard for multimedia conferencing is the H.320 standard. This is a protocol that defines how real-time multimedia communications and conferencing are handled over switched or dedicated ISDN telecommunication links. The protocol is an international standard of the International Telecommunications Union (ITU), and it was adopted in 1990. Multimedia refers to the fact that the standard covers voice, video, and data. The standard is an umbrella standard and includes many other protocols that describe, as an example, how to encode and decode voice and data, how to setup calls between terminals, and how to handle data connections.

H.323 is an umbrella set of standards defining real-time multimedia communications and conferencing over packet switched networks. Version 1 was adopted by the ITU in 1996 and Version 2 was finalized in 1998. Like H.320, it is a part of a family of H.32X standards. H.323 borrowed many of the H.32X standards used by H.320, especially those for encoding/decoding the audio/video streams and the data sharing protocol (T.120), but it defined a new set for handling communication over the Internet.


Nortel Networks 20

The key ITU standards and their function in a video terminal context are as follows:

H.221: Frame structure for a 64 to 1920 Kbps channel in audiovisual teleservices

H.224: A real time control protocol for simplex applications using the H.221 LSD/HSD/HLP channels

H.225: Call signaling protocols and media stream packetization for packet-based multimedia communication systems

H.230: Frame synchronous control and indication signals for audiovisual systems

H.231: Multipoint control unit for audiovisual systems using digital channels up to 2 Mbps

H.242: System for establishing communication between audiovisual terminals using digital channels up to 2 Mbps

H.243: System for establishing communication between three or more audiovisual terminals using digital channels up to 2 Mbps

H.245: Control protocol for multimedia communication

H.261: Video codec for audiovisual services at P x 64 Kbps

H.263: Video coding for low bit rate communication

H.264: Advanced video coding for generic audiovisual services

H.281: A far end camera control protocol for videoconferences using H.224

G.711: Pulse code modulation (PCM) of voice frequencies

G.722: 7 kHz audio-coding within 64 Kbps

G.722.1: Coding at 24 and 32 Kbps for hands-free operation in systems with low frame loss

G.722.2: Wideband coding of speech at around 16 Kbps using Adaptive Multi-Rate Wideband (AMR-WB)

G.728: Coding of speech at 16 Kbps using low-delay code excited linear prediction (LD-CELP)

G.729: Coding of speech at 8 Kbps using conjugate-structure algebraic code excited linear prediction (CS-ACELP)


Nortel Networks 21

5. Solution Topology The diagram below shows our same reference enterprise seen earlier, with an MCS VoIP solution added along with four Polycom room systems. Two Polycom VSX 7000 room systems are deployed in the HQ campus, one in Metro Site 1 and the fourth in Remote Office 1. To support multi-point conferencing at the scaling needed for this reference customer, a Polycom MGC 100 is installed at the HQ site.

Figure 2: Video Conferencing Reference Solution

The addition of a VoIP solution to the reference network demands that measures be taken to increase network availability. The remote offices have had additional switches and routers added along with a second WAN link to increase network availability. The Metro offices also have added network elements and connectivity to the Metro WAN service has been upgraded to include a second link, for redundancy purposes. The VC systems and data applications also benefit from this added network availability. With this increase in network availability, ISDN circuits for VC backup connectivity is not required. The above diagram is a high level view of connectivity and does no include any additional components that the enterprise may consider deploying to increase VoIP and VC security. If a network solution at the Enhanced level of security were to be deployed, for instance, a secure tunneling device would be added to encapsulate VoIP and VC traffic in secure tunnels across the WAN. Likewise, a Secure VoIP Zone (SVZ) could optionally be included in the network to protect the MCS VoIP servers. Details of the various levels of security and deployment techniques can be found on the Nortel Networks web page in a positioning paper titled Secure Telephony Solution. This paper and it’s associated appendix can be found here http://www.nortelnetworks.com/solutions/security/doclib.html.

DMZ

WWW DNS SMTP FTP

L2 / L3 Core

L2 / L3 Core

LARGE HQ

CAMPUS

DHCP, DNS

Building 1 Building 2

DHCP, DNS

DHCP, DNS

Metro Site 1

Metro Site 2

DHCP, DNS

NOC

Remote Office 1

Remote Office 2

WANWAN

MetroMetro


Nortel Networks 22

5.1.1 Call flow examples The following call flow diagrams are representative of some of the call types supported in this solution. The SIP signaling paths are shown in red and the RTP bearer paths are shown in green. This is consistent for all the diagrams that follow.

5.1.1.1 MCS Point-to-Point Call

The signaling and bearer paths for MCS point-to-point calls are straightforward and are shown below.

Figure 3 MCS Point-to-Point Call

We can see that the bearer path is peer-to-peer while signaling is to the MCS system.

5.1.1.2 MCS Multipoint Call

Multipoint conferencing in an MCS solution is accomplished using the MCS conferencing server.

Figure 4 MCS Multipoint Call

In this case, all media streams are directed to the MCS Media Application Server (MAS) once the calls are established. There is an interim step that establishes point-to-point calls before turning over all streams to the MAS and this step is the same as a point-to-point call setup.

5.1.1.3 VSX Point-to-Point Call

This is the basic Polycom room-to-room call process. The VSX end stations signal to the MCS system just as was previously shown in the MCS Point-to-Point call scenario.

Figure 5 VSX Point-to-Point Call

To the MCS, the VSX end stations appear as multimedia capable end stations. The bearer path between end points is peer-to-peer.


Nortel Networks 23

5.1.1.4 VSX Multipoint Call

In this type of call, the VSX sends signaling information to the MCS and MGC is the “meet me” point for RTP streams.

Figure 6 VSX Multipoint Call

5.1.1.5 MCS to VSX Call

In this call model, the Polycom VSX room system must use SIP to communicate with the MCS to facilitate getting the call established.

Figure 7 MCS to VSX Call

5.1.1.6 MCS and VSX Multipoint Call

This is an example of an MCS Multimedia desktop client joining a VC that includes more than a single VSX. Once again, all SIP signaling is done to the MCS and the MGC provides multiport bridging functionality for the RTP streams.

Figure 8 MCS and VSX Multipoint Call


Nortel Networks 24

5.2 Interoperability There are a large number of VC installations that are currently deployed that must interoperate with this MCS/Polycom SIP based VC solution. Although the advantages of a SIP based solution are clear, it’s unreasonable to expect all systems to migrate to SIP. The legacy VC systems will likely remain in use for some time because of the investment that enterprises have made in the hardware, making an interworking solution necessary. Interoperability between the currently deployed H.323 and H.320 based VC systems and the new SIP based VC systems can only be accomplished with the use of a Gateway/Gatekeeper function.

The H.323/H.320 Gateway in this solution is the Polycom MGC. All H.323 and H.320 devices signal to the MGC which in turn signals the MCS system using SIP. All H.323 and H.320 endpoints register with the MCS through the Gateway function. This registration process ensures that communications can be established between endpoints of SIP, H.323 and H.320 network domains.

Figure 9 H.320/H.323/SIP Interoperation

The figure above shows the signaling and bearer paths when one VSX conference system is running legacy H.323, two other end points are H.320 endpoints and all must communicate with a SIP environment. The H.323 and H.320 Gateway function in the MGC provides the interworking to the SIP domain.

The MCS Multimedia client operation and VSX SIP end point operation remain the same as seen earlier in a pure SIP network.

5.3 Performance There are no published requirements for the performance of VC systems but it is likely that the expectation of voice quality is the same as that for a VoIP solution. Both the video and audio quality is a function of CODEC used for the call, as well as the network QoS implementation.

H.323 Endpoint

SIP Endpoint

H.320Endpoints H.323

SIP

RTPH.320

H.323

SIP

RTPH.320

SIP Domain

H.320 Domain

H.323 Domain


Nortel Networks 25

5.3.1 QoS When VC solutions are deployed into an existing IP network, new demands are placed on network resources. These demands can only be resolved through the implementation of sound QoS techniques. Video Conferencing traffic requires high performance from the network as it is an interactive type of service, much like VoIP traffic.

Nortel Networks has a well defined priority scheme to ensure different traffic types are given the appropriate priority. As shown in the table below, VC traffic is categorized as “Real Time, Delay Tolerant” and as such, an IP Service Class of Platinum is assigned. It can be seen that the Layer 3 DSCP should be AF41 (0x22) for the Video component and EF (0x2E) for the Audio component. Signaling traffic is marked as CS5 (0x28). At Layer 2, the 802.1p priority value should be set to 5 for Video and 6 for Audio and Signaling.

The different traffic types can often be marked by the end device based on the configuration. If marked by the end device, the switch port that the end device connects to must honor the marking. The following rules, as defined by Nortel Networks1, can be used as a guide when configuring QoS.

Traffic Category Application IP Service Class

DSCP 802.1p

Network Control Alarms and heartbeats Critical CS7 7 Routing table updates Network CS6 7

Real Time, Delay Intolerant

IP Telephony Premium EF, CS5 6

Real Time, Delay Tolerant

Video Conferencing Platinum AF4X, CS4 5

Audio/Video on Demand Gold AF3X, CS3 4 Non-RT, Mission Critical

Interactive eBusiness - Transaction Processing

Silver AF2X, CS2 3

Non-Interactive

Email, FTP - Store and Forward

Bronze AF1X, CS1 2

Non-Real Time, Non Mission Critical

Best Effort Standard DE, CS0 0

Table 2 QoS Recommendations

The following recommendations can aid in providing a solid end-to-end QoS implementation; End Device connecting to a L2 Switch (i.e. NN Ethernet Switch 450)

o If device is dedicated to port (i.e. MCS, Polycom) • use port prioritization and set 802.1p

o If device can pre-mark 802.1p (i.e. i2050) • Use ingress filter to prioritize packets by 802.1p tag

o If port is shared (i.e. i2004 / PC); • Setup ingress filter to prioritize packets by 802.1p tag (Rel. 1.3 of i2004)

End Device connecting to a L2+ switch (i.e. NN Ethernet Routing Switch 8600)

o If device is dedicated to port and can mark DSCP • Setup port as trusted core port. Use DSCP to set 802.1p tag

1 Ralph Santitoro, Nortel Networks QoS and Policy Based Routing


Nortel Networks 26

o If port is shared and device can mark DSCP • Setup port as trusted core port. Use DSCP to set 802.1p tag or • Setup port filter range (requires port range to be setup on application).

Use this range to mark DSCP, 802.1p and set prioritization

Guidelines to satisfy user QoE expectations can be found in an American Standards Institute (ANSI) document titled Quality of Service for Business Multimedia Conferencing. The reference number for this document is ANSI T1.522 and it provides the guidelines for Audio and Video Skew as seen in the table below.

User - User A/V Sync Tolerance

Perceptible Level

"+20ms to -40ms"

Acceptable Level

"+80ms to -80ms"

Max A/V Skew +80ms to -80ms Network Not

Specified

Table 3 Audio/Video Skew

The same ANSI document provides guidelines for delay and these numbers are shown in the table below.

Audio & Video User to User 1

Way Delay

Perceptible Level

150 ms

Acceptable Level

400 ms

Max TE Delay = 250ms

Max Network Delay = 400ms - Max TE Delay =

150ms Max Network Delay

Variation - 33ms to 40ms

Table 4 Maximum One Way Delay

Excellent references for QoS configuration details can be found in the following documents; Using the BayStack 470-48T 10\100\1000 Switch – Part No. 212791-C http://www116.nortelnetworks.com/docs/bvdoc/baystack/doc_pdf/212791c.pdf Passport 8600 – Configuring QoS and IP Filtering http://www116.nortelnetworks.com/docs/bvdoc/passport_8000_3.7/doc_pdf/316433-C.pdf Technical Configuration Guide for BayStack 5510 QoS and IP Filtering http://www116.nortelnetworks.com/docs/bvdoc/ene_tech_pubs/bs5510_tcg_qos_public.pdf

5.4 Traffic Engineering The VC bandwidth usage will vary and is dependent on the CODEC used (Ref Section 4.6). Typical low bit-rate conferencing requires approximately 40Kbps while high quality


Nortel Networks 27

conferences can consume 2Mbps of bandwidth. The high resolution room systems with large monitors that are often installed in executive boardrooms are examples of systems that require high bandwidth. A home worker using a desktop PC over a DSL service or a teleworker using a LapTop would require significantly less bandwidth.

For the purpose of traffic and network engineering, the media and signaling flows extremely important due to the real-time response requirements. The media and signaling flows must be supported with low latency and high priority on the IP network and packet loss is an important consideration. Video traffic is very sensitive to packet loss and can have a sever impact on end user QoE.

In addition to the bearer and signaling flows, the management traffic between the Management Module and the managed entities also need to be considered for proper network operations.

When considering bandwidth consumption, the overhead of the lower layers cannot be discounted since it can become significant. The next diagram demonstrates how the overhead associated with Ethernet and IP contribute to the traffic load that can be expected on a network. The original 1000 Byte video payload has an additional 66 Bytes of overhead (excluding Interframe Gap and 802.1Q field) that needs to be considered when calculating network bandwidth requirements. Forty bytes are needed for IP overhead while the Ethernet overhead is an additional twenty bytes.

Transporting the same 1040 Byte payload (Video and IP) over an ATM or Frame Relay service requires that the packet be segmented into several ATM cells or Frame Relay packets. Special attention needs to be paid to lower speed WAN links and the current traffic profiles for these links must be understood before the additional VC traffic is added. The density and location of VC users could necessitate upgrading these WAN links so that (1) the existing services are not adversely affected by the added traffic and (2) the expected VC traffic can be accommodated. Each enterprise will have unique WAN requirements and sweeping generalities are difficult to make.

The MCS Network Engineering and Deployment Guide (NN10313-191 MCS 5100 3.0) available from the Nortel Networks technical documentation site has an entire section dedicated to Traffic Engineering and is a “must read” when considering an MCS deployment. Many of the principles used for determining voice traffic patterns can be

directly applied to VC traffic distribution.

Figure 10 Ethernet & IP Overhead

Ethernet8 6 6 2 41040

CRCIP Payload

TypeSource

DestinationPreamble

12 4 4 8 12 1000

Video PayloadRTP HeaderUDP Header

Source

DestinationHeader

IP Layer


Nortel Networks 28

The physical location of the MGC and MCS servers has an impact on how traffic flows across the enterprise and should be selected carefully. Looking at the call flows in Section 5.1.1, it can easily be seen how the signaling path can be affected when an MGC is installed in a location that is a WAN hop away from the MCS system. Likewise, the bearer path for multipoint calls that use the MGC as a meet-me point for end clients are impacted by the choice of location.

5.5 Scalability The scaling considerations of a VC system must take into consideration the number of expected simultaneous conference sessions, the bandwidth per session and the available network bandwidth resources. There are usually only a relatively small number of participants in any particular Video Conference and scaling, in terms of network bandwidth, is not onerous in isolation but can be a considerable incremental load on the existing network infrastructure.

5.5.1 Multipoint Gateway Controller The Polycom MGC is available in a single-slot (MGC-25), 8-slot (MGC-50) or a 16-slot (MGC-100) configuration (Reference Table 1 in Section 3).

5.5.2 MCS 5100 The MCS 5100 platform scaling for video is not an issue at initial deployment since all multipoint conferencing will be accomplished using the Polycom MGC element.

It should be noted that an MCS solution supports up to 10,000 active subscribers using Sun Fire V100 servers or up to 60,000 active subscribers using Sun n240 servers. Additional capacity and redundancy configurations can be accomplished with multiple server implementations. This flexibility in scaling options ensures that the target market, Medium to Large enterprises where high-end Video Conferencing solutions are required, can be comfortably met.

5.6 Reliability The central technologies of this joint solution offering are the MCS service platforms. All respective MCS application services can be deployed in complete high availability mode for N+1 redundancy and reliability. In the case of deployments where redundancies and reliability are not as critical for particular services, N+1/n redundancies can be provided by merging application services onto secondary server platforms. It is recommended to provide for N+1 service redundancy for call management and control. Failover of services occur within the MCS sub-systems so as to provide total transparency to any particular platform outage provided that the correct accommodations for redundancy have been made. This needs to be considered not only from the perspective of the service but from that of the capacity of the service as well. MCS deployment guidelines


Nortel Networks 29

will assist in engineering the appropriate redundancies for the correct service level requirements.

Network reliability can be addressed by ensuring that network is already optimized for VoIP reliability.

There is a need for a Video Conferencing solution to be highly reliable which places demands on the supporting network, individual end stations and the multipoint conferencing elements.

There are well documented methods for providing network resiliency. A good source of this information can be found in a paper titled “LAN Switching Resiliency Engineering Application Note”. A soft copy of this paper can be found here;

http://www116.nortelnetworks.com/docs/bvdoc/ene_tech_pubs/lan_switching_resiliency_appnote_v1_1_external.pdf

There is no redundancy for the VC room system end-points, just as there is no redundancy for an individual desktop workstation. Room systems are much like a desktop workstation and similar support/sparing strategies should be considered. A single Ethernet connection is used from the end station which connects to a single switched port (typically on a wiring closet switch), both of which represent single points of failure.

There is a capability of multi-homing end stations such that if a particular MGC is unavailable when a conference is to be set up, an alternate MGC can be used. Each enterprise must weigh the cost of deploying multiple MGC platforms to provide this level of resiliency.

In the initial phase of interoperability, redundancy with the MGC platform will be based on a singular chassis. The MGC platform provides redundant power and fan supplies as well as redundant services across modules within the chassis. The failure of one module within the chassis will in turn cause a fold over to the next available service module. This is also the case in instances of service overflow. Consequently, this approach is useful for service redundancy as well as scaling.

In later releases, this basic concept will be extended into a multi-chassis hunt environment which affords cross redundancy between the MCS call systems and the MGC platform environment. In addition, preferential gateway routing can be used in a complimentary fashion so that the correct hunt priority order can be matched according to the appropriate dialing pre-fixes and area codes.

The figure below illustrates a multi-chassis hunt configuration.


Nortel Networks 30

Figure 11 MCS Multi-chassis Hunt Configuration

5.7 Security A Video Conference between two Polycom VSX 7000 systems can be set up using AES 128 Bit encryption between these points. Unfortunately, if more that two end points need to participate in a conference using the MGC, the ability to encrypt the video/audio streams is lost. The MGC platform does not support and encryption capabilities.

When a conference between a Polycom end point and MCS end point is required, there is no common ability to secure the video/audio stream.

End-to-End security between all types of end points is possible only through the use of IPSec tunneling techniques. In this type of arrangement, a tunneling device (i.e. Contivity) would be co-located with the conferencing end point and IPSec tunnels established, either permanently or at call set-up time. Although this could be an expensive solution, it would provide an interim solution until common encryption mechanisms are developed.

All MCS and Polycom servers in the solution must be protected from attack from internal and external sources. In order to accomplish this, as a minimum, all servers must have published and demonstrated OS hardening techniques. Video Conferencing is not a lifeline service and measures such a used in a Secure VoIP deployment (i.e. Secure Voice Zone) are not likely necessary. Of course should an enterprise already have a SVZ deployed, the MGC can be installed in the SVZ along with the MCS servers.

5.7.1 NAT & Firewall traversal Requirements Peer-to-peer applications such as Voice over IP (VoIP) and Video Conferencing typically use one UDP or TCP port to establish additional media streams (on UDP). The protocols

SIP DomainSIP Domain

MCS 5x00 HA Mode

1xx1xx

2xx2xx

3xx3xx4xx4xx

2 or more IP Blades

2 or more IP Blades

2 or more IP Blades

2 or more IP Blades


Nortel Networks 31

themselves (SIP, H.323, etc.) typically use well known ports, but the ports used for media are negotiated dynamically end-to-end. Some protocols (e.g., H.323) may even use a dynamic port for a second signaling channel. The protocols include IP addresses and port number at the application layer for setting up media stream. The presence of NATs which unilaterally changes IP addresses and port numbers is very troublesome for peer-to-peer applications. In this document, both NAT and Firewall requirements are considered. However, the boundary between a NAT and a Firewall is often blurry. For example, the difference between the various flavors and Cone NATs are their intrinsic Firewalling capabilities. Also, a Symmetric NAT and a Port Restricted Cone NAT have the same Firewalling capabilities. This document makes no attempt to partition what is NAT versus what is Firewall. While the issues surrounding NAT & FW traversal are not trivial, Nortel Networks has condensed its solution to the problem into two major approaches. The first is that of the Application Layer Gateway. This approach is typically used within the enterprise environment and is a process that is embedded into firewall and VPN products. The second approach is that of the Media Portal. This approach is typically used by service providers for managed service deployment. The RTP media portal is an extended sub-system of the Multimedia Communications Platform (MCP) environment and is typically used with MCS 5200 deployments.

5.7.1.1 Application Level Gateway (ALG)

Not all applications lend themselves easily to translation by NAT devices, especially those that include IP addresses and TCP/UDP ports in the payload. Application Level Gateways (ALGs) are application specific translation agents that allow an application on a host in one address realm to connect to its counterpart running on a host in different realm transparently. An ALG may interact with NAT to set up state, use NAT state information, modify application specific payload and perform whatever else is necessary to get the application running across disparate address realms. It should be noted however that ALGs may not always utilize NAT state information. They may glean application payload and simply notify NAT to add additional state information in some cases. ALGs are similar to Proxies, in that, both ALGs and proxies facilitate Application specific communication between clients and servers. ALGs do not use a special protocol to communicate with application clients and do not require changes to application clients. Proxies, unlike ALGs, use a special protocol to communicate with proxy clients and relay client data to servers and vice versa. Not all Firewalls have the ability to support ALGs, making it necessary to configure pinholes to allow uninterrupted traffic flow. Care should be taken when deploying multimedia applications that are accessible only through firewalls careful engineering and testing is required. Likewise, not all NAT implementations are alike and some implementations are less “friendly” to multimedia traffic than others. A description of the different NAT types can be found in RFC 2663 - IP Network Address Translator (NAT) Terminology and Considerations.


Nortel Networks 32

5.7.1.2 The MCP RTP Media Portal

The MCP FW/NAPT Traversal Strategy enables obscured clients to establish and maintain access with the service engines. It does so within the constraints of existing security policies that govern client activity thereby enabling the use of advanced multimedia features without jeopardizing security. Enterprise subscribers are usually situated behind FW/NAPT devices. They may also reside in networks that have private IP addresses which are not accessible from outside the enterprise. In order for such users to take full advantage of advanced telephony and multimedia features they must be accessible from outside the enterprise. The MCP FW/NAPT Traversal Strategy enables such Enterprise subscribers to traverse the intervening network and access the service engines. Similarly, the MCP FW/NAPT Traversal Strategy provides the service engines access to the Enterprise subscriber. In this way, the Enterprise subscriber is able to utilize a wide array of advanced originating and terminating services. Please see the detailed documentation on the MCP Media Portal available through the Nortel Networks documentation web page.

http://www130.nortelnetworks.com/cgi-bin/eserv/cs/main.jsp This document describes the MCP FW/NAPT Traversal Strategy and details the functionality required in both the signaling-plane and the media-plane for SIP Clients that wish to interact with the MCP solution using this Patent Pending Nortel Networks technology.


Nortel Networks 33

5.8 Deployment Considerations 5.8.1 Videoconference Room Design

Three standard room configuration suggestions—Small, Medium, Large—with the following specifications: Small Room: Room Size: L=22’ x W=15’ x H=9’ (330 sq.ft) Medium Room: Room Size: L=26’ x W=16’x H=9’ (416 sq.ft) Large Room: Room Size: L=31’ x W=17’ x H=9’ (527 sq.ft)

5.8.2 Seating Recommendations The seating recommendation is based on the specified number of people at the conference table that are simultaneously on camera in the fully wide-angle mode.

Table Description Small Table 5-person Formica Top, Hardwood Edge Medium Table 9-person Formica Top, Hardwood Edge Large Table 13-person Formica Top, Hardwood Edge

Table 5 Seating Capacity and Table Recommendation

The figures that follow, demonstrate the recommended seating arrangement for deployment that accommodates the three room sizes supported.

o Small Room: 5 person room - A typical room layout is shown in Figure 12 o Medium Room: 9 person room - A typical room layout is shown in Figure 13. o Large Room: 13 person room - A typical room layout is shown in Figure 14.

Figure 12 Small Room - Five persons


Nortel Networks 34

Figure 13 Medium Room - Nine Persons

Figure 14 Large Room - Thirteen Persons

5.8.3 Location & Environment The Videoconference room should be located near the center core of the building. It should be located away from the following:

o Exterior walls with windows o elevators o Washrooms o Cafeteria o High traffic areas o High noise environments such as server rooms, mechanical rooms, etc.


Nortel Networks 35

5.8.3.1 Wall Construction

The following recommendations can be made in the wall construction and material used.

o All walls shall have a Sound Transmission Class Sound Transmission Criteria (STC) rating of 52dB

o All walls of the room shall be contiguous from floor slab to ceiling slab

o All wall penetrations must be sealed

o All non-cement walls shall have a construction as follows or equivalent:

• Two layers of 1/2 inch drywall on one side and one layer on other side of 16-

inch 0. C. 2 1/2 inch steel channel studs with fiberglass insulation in cavity having a density of 3/4 pcf.

• Walls shall be painted light in any color tone. (Suggestion: Light gray or

eggshell are best suited for a successful production) Walls facing the camera shall not have any printed fabrics or painted designs.

5.8.3.2 Ceiling Construction

The following recommendations can be made in the ceiling construction and material used.

o Suspended ceiling

o 5/8 inch thick acoustic ceiling tiles

5.8.3.3 Floor Covering

The following recommendations can be made in the floor construction and material used.

o Carpet for Small, Medium and Large rooms

o No color restrictions

5.8.3.4 Lighting

The following lighting recommendations can be made.

o Lighting plan shall provide evenly distributed fluorescent lighting

o Light levels at all positions in room shall be 60 foot candles (except in front of the

video monitors where light levels shall be reduced by 20 foot candles to avoid wash-out of the video monitors

o Color temperature of lighting shall be 3200 degrees Kelvin

o Blackout blinds shall be installed to cover any and all existing windows in the room during Videoconferences


Nortel Networks 36

o Alternate dimmable incandescent lighting shall also be provided at the interior

designer's discretion, this lighting must be independent of the main fluorescent lights

5.8.3.5 Heating Ventilation Air Conditioning (HVAC) System

The following HVAC recommendations can be made.

o Air flow shall be provided through multiple large-area supply grills to reduce flow

noise o Ducts shall be lined with approved sound absorptive material

o Main air supply ducts shall NOT pass over or near the Video Conference room

o Plumbing shall not pass over the Video Conference room

o Ambient noise inside the room shall not exceed NC-30 (NC=Noise Criteria)

o Power consumption of Video Conference equipment is approx. = 1200 W

5.8.3.6 Door

The following door recommendations can be made.

o Shall be located such that people entering are not immediately on camera

o Doors shall have a Sound Transmission Criteria (STC) rating of at least 5OdB

o Comprehensive acoustic seals shall be applied to the doorframe

o Door "peephole" shall be provided

5.8.3.7 AC Power Circuits

The following power recommendations can be made.

o One 15-Amp circuit shall appear at the front of the Videoconference room to power

the Videoconference equipment.

o All other power as required by the client for other purposes

5.8.3.8 Cable ways

Provisions shall be made to facilitate the safe running of cables from the videoconferencing system electronics location to the Video table (microphone cord). If provisions cannot be made to route the cables through the floor, the cord may be run on top of the floor using flexi-duct (a cable-cover duct that lies flat on the floor which will accept cables up to ¾-inches in diameter).


Nortel Networks 37

5.9 Configuration Guidelines An existing network must be examined and a pre-deployment assessment conducted before deploying any VoIP solution and this is true for Video Conferencing solutions as well. A network assessment is mandatory and will identify the following;

o Existing bottlenecks

o Link utilization

o Areas of instability

o Network Element software levels

o Network Element QoS capabilities

o Physical Port count

o Resiliency/Redundancy

Network changes can be made based on the pre-deployment assessment findings to deliver the expected QoE to the end users.

The configuration guides for the MCS 5x00 can be found at www.nortelnetworks.com.

Polycom configuration information can be found at www.polycom.com.

Given the statements above, there are some general considerations that need to be made in the implementation of the joint solution in its current phase in offering. Polycom currently does not support the MCS method of user authentication. Consequently, there are two methods that are available to support these systems. The first is to disable authentication on the MCS system. This approach will allow for the dynamic usage of IP addresses by the Polycom systems. In instances where this is not acceptable, the recommendation is to use static IP addressing for Polycom systems and enter them as ‘trusted nodes’ in the MCS system. While this prevents dynamic addressing use it preserves the security of the overall system. Also, considering that most Polycom systems are stationary, static IP addressing is not a prohibitive requirement. As a result, the trusted nodes approach is the recommended approach.

Further accommodations need to be made for the incorporation of the MGC MCU/gateway system. Please see the deployments notes and considerations below for procedures.

The following section is a basic cheat sheet for how to setup the MGC as a SIP Gateway off the MCS in 3.0. There are two other methods initially tested but had short comings or issues which could not be overcome for Release 3.0. The first was to setup the MGC as a user in the system. The MGC can have multiple boards but there wasn’t a way to support the multi-board configuration. The second was to re-use the Meet-Me routable service. This would have been preferred but since this service was not developed in a generic fashion but rather specific to the MAS it resulted in the MGC not responding appropriately with respect to management of the box. The selected approach was to setup the MGC as a SIP Gateway and exploit both the route advancement via trunk groups which allows support multi-board units and a redundancy strategy as well as exploit the translation / telephony routing capability of the MCS. The only limitation with using Telephony translations is that only numeric numbers can be used for various conference ids and so forth. The following describes the process for provisioning the MGC. There are 3 major steps summarized as follows:


Nortel Networks 38

1. Add the MGC IPs to the Authenticate node list within the Session Manager (AppSvr) via the Management Console. This will make the MGC a trusted node. This is done to eliminate the need for the MGC to register as well as removes the requirement for it to support the Nortel firewall traversal method.

2. Provision the MGC as a Gateway at the System level via the MGC Provisioning Client

3. Provision the Telephony Routes for terminating to the MGC

The following sections depict how to setup each of the above steps.

5.9.1 Step 1: MGC as Trusted Node. To add the MGC as a trusted node startup the Management Console. Traverse down to the Session Manager (Appsvr) component as depicted in the picture to follow. To modify, you will need to Lock the component first, so right click and select Lock.

Figure 15 Locking the component

Once it is locked, you can then perform the Modify on the component. The following figure shows the window that is opened after selecting Modify. Add the IP(s) to the Authorized Node IP Address table. This picture doesn’t show the Apply button because it was just a query. Regardless, once you have added them hit Apply and then Unlock the component.


Nortel Networks 39

Figure 16 Component Modify Window

5.9.2 Step 2: Provisioning MGC as Gateway Within the Gateways folder under Provisioning (top level), select the Add Gateway. The following picture shows the two gateways that were added for each board in the MGC that was being used. Things to note, the Gateway Type used can be either Non-Compliant or Generic. However, this may change going forward because the message size needs to be reduced to enable the use of the RTP portal for the MSC 5200 configuration. Discriminator files put in place for the demo testing performed when the MGC was configured as a user but were never added as gateway types. Efforts are currently under way to determine if these will be added or the generic type will be modified to strip out the same information that the discriminator files were doing. This is the preferred method because it could then be used for other devices in the future. The other thing to note is the location. The specific location was setup for this example to prevent the portal from being inserted automatically into the call. This was acceptable for the MCS 5100 demonstration solution. This may or may not be standard configuration but it was needed in the demonstration to simulate the MCS 5100 style solution for the Polycom team using the remote system.


Nortel Networks 40

Figure 17 Add Gateway Window

The following picture is just a close up view of the MGC gateways presented in previous picture.

Figure 18 Gateway Window

This following picture is the detailed provisioning for the gateway. This is what was entered when an Add Gateway was initially performed. A gateway must be added for each of the conference board IPs within the MGC. The IP is provisioned in the maddr


Nortel Networks 41

field as part of the Gateway host field. Please note the gateway type comment made earlier.

Figure 19 Update Gateway

5.9.2.1 Add Gateway Route

The next step is to setup a gateway route for each of the MGC. This Route is what will be used to enable multiple trunk groups for each of the boards within the MGC. The following picture shows the list of gateway routes on the system of which an MGC route was define. This is how the multi-board MGC that Polycom was tested once the external system was setup. The Route is called Polycom_MGC_Route. Please note the Re-Order is enabled to allow for the route advancement to the other boards if one goes down or is busy (this becomes an option once multiple trunk groups are associated to the route.

Figure 20 Gateway Routes


Nortel Networks 42

The following picture is the definition of the Gateway Route it self. This is what was entered when performing the Add Route.

Figure 21 Add Route Entries

5.9.2.2 Add Trunk Groups

The following is a picture of the Trunk Groups provisioned on the system. The Polycom_MGC_TrkGrp1 & Polycom_MGC_TrkGrp1 are the ones of interest.

Figure 22 Trunk Groups


Nortel Networks 43

The following picture is the definition of the Trunk Group for the first IP board in the MGC. This is what was entered when performing the Add TrunkGroup.

Figure 23 Trunkgroup Provisioning

The following picture is the definition of the Trunk Group for the second IP board in the MGC. This is what was entered when performing the Add TrunkGroup.

Figure 24 TrunkGroup Parameters

Please note if more than one trunk group is assigned to the Route then the Re-order link will become visible on the List Routes page. You can enter that link to determine the order for trunks i.e. which should be used first, second and so forth. Here is a picture of the re-order page.


Nortel Networks 44

Figure 25 Reorder Trunk Groups

5.9.3 Step 3: Provisioning Telephony Routes for the MGC Gateway Now that the MGC is provisioned as a gateway, the next step is to provision the telephony routes for getting to the MGC. Please note, in this example, the telephony route takes the user to a specific conference ID on the MGC that was being tested. However, the Telephony Route translation provisioning is very flexible. More than likely, the desired dial plan will be one where if the user dials a number starting with xxx then he is routed to the MGC. The rest of the numbers in the string will be used by the MGC itself. Again the following pictures depict the provisioning after the fact. An attempt is made to point out when you need to actually perform Add operations as oppose to the “modify” or “view”. To setup Telephony Routes for the MGC go to the desired domain for which you want to setup telephony routes so that the users can access the MGC i.e. Provisioning->Domain->(the desired domain)->Telephony Routes The following picture is what resulted from performing a List Telephony Routes under this link.

Figure 26 List Telephony Routes


Nortel Networks 45

The first step is to Add a Telephony Route. The following picture depicts what was entered when the MGC1_TelRte Telephony Route was added. Please note when your first add it there will not be a RouteList to select so you will have to return to and select one once it has been provisioned. Also note, in this example, the route is defined so the user has to explicitly dial the 5 digits to get to the MGC. There is a great deal of flexibility for how to setup the routes based on what you want the user to dial. This isn’t what you would typically do for a large deployment. This is just an example.

Figure 27 Modify Telephony Route

The next step is to add a Route List and associate a Telephony Route to it. The following picture depicts the Telephony Route List which was provisioned.


Nortel Networks 46

Figure 28 Route List

The following picture is what was provisioned when performing the Add RouteList. After adding the RouteList you need to go back and List the Telephony Routes again, select the route list link which will take you to the Modify Telephony Route. Select the desired Route in the list and save.

Figure 29 Modify Route List

At this point you also need to perform a Change Parameters for the Telephony Route list. List the Telephony Routes again. For the provisioned Telephony route, select the Change Parameters link. The following picture depicts what was provisioned for the telephony route.


Nortel Networks 47

Figure 30 Modify Route List Parameters

This completes the provisioning for the MGC off the MCS. Any user within the domain should be able to access the MGC by dialing the digits as defined for the desired dial plan defined and setup via the telephony routes. You can test the translation by using the Translation tool.

5.9.4 Provisioning Polycom VSX endpoints There are two basic requirements/steps for provisioning VSX devices off the MCS.

1. Add the VSX IP to the Authenticated Nodes table within the Session Manager

(Appsvr) component via the Management Console for the MCS. a. This is required for two reasons. First, the VSX in Rel 7.0 doesn’t support

authentication challenges for methods. So, if REGISTER is challenged the VSX will fail. If method authentication is not enabled then this step isn’t necessary. Second, the VSX in Rel 7.0 doesn’t support Nortel’s firewall traversal method.

2. Add a SIP user account for the devices. This user will be provisioned into the VSX itself.

We didn’t see a need to show examples of these because the first is the same as depicted for the MGC.


Nortel Networks 48

6. Acceptance Testing Once a system (particularly a room system) is physically installed, there are a number of simple operational tests that can be performed to ensure proper operation.

Verify all basic system functions

o Video monitor operation – for a dual display system local image on one screen remote on second, for single display picture in picture toggling local/remote vide full screen.

o Camera pan/tilt/zoom/tracking – verify function of the camera pan, tilt, zoom, presets and voice tracking if so equipped. Verify remote camera control in a call if the systems are configured to permit it.

o Remote control functions – allows access to system set up and operational functions. Local camera, pan, tilt, zoom, microphone mute, unmute, volume adjust, call set up, hang up functions

o Remote management functions – allow remote access to administer and control a video system. Verify connectivity to system and access to all control and configuration menus.

o Microphone operation – mute, unmute, pick up coverage for available seating positions.

o Audio clarity - in a call with a participant at the far end, confirm audio clarity and speech intelligibility in both rooms. This should be done both point to point and through the MCU.

o Network connectivity – remote management access checks basic connectivity. A series of calls placed to and from the system will verify connectivity and operational performance. The calls should be placed to emulate user call patterns if possible, remote locations of interest and at similar times of day. The call performance should be verified by observing the received audio and video signals as well as the call statistics menu displays.

7. Migration Migrating from a legacy VC system (ISDN Based) to a system based on IP-SIP requires planning but the benefits are clear. Some of the benefits include

(1) increased video rates can quickly be realized (LAN vs. ISDN bandwidth)

(2) costs can be reduced (ISDN circuits and connect costs)

(3) and easier operations (simplified call set-up)

Many of these benefits are discussed in an article available from the Nov 2003 edition of Business Communications Review titled “Moving ISDN-Based Videoconferencing Onto the IP Network”. This paper is available in softcopy from the Webtorials web page here http://www.webtorials.com/abstracts/BCR71.htm.

Although the paper discusses a migration from ISDN - H.323, the recommendations are directly applicable to an ISDN - SIP migration.

If the enterprise currently has a high performance Polycom based room systems it will include a Polycom MGC gateway/bridge element. This existing MGC can be specified


Nortel Networks 49

with sufficient on-board ISDN and MUX resources to provide bridging capacity to support the legacy rooms as well as any new SIP based room systems. The bridge then provides the gateway connections between the legacy ISDN rooms and any SIP end points.

If there is existing ISDN bridging capability, the MGC ISDN requirement can be scaled back to support limited SIP to ISDN gateway functionality. The MGC then provides the gateway functionality and a cascaded link to the legacy ISDN bridge supports the legacy ISDN rooms. This second scenario makes more sense if the intention is to replace existing legacy ISDN systems with SIP based systems as they reach the end of their operational lives.

8. Support Services To be determined

9. Training To be determined

10. Technical Support To be determined


Nortel Networks 50

11. Appendix A – Feature Matrix

Nortel MCS 5100 With MultiPoint Video

Conferencing Only

Nortel MCS 5100 With Polycom VSX and

MGC Integrated IP phones Equpment Desktop PC multimedia

client (video, IM, soft phone, buddy list, etc.)

& Software Desktop video appliance (video phone or VSX3000 or similar) No

Group video systems No MCU Gateway No Unified provisioning and

management system (endpoint priority) No

IM and Presence Capability-aware presence

(e.g. video enabled) No No

Able to initiate point to point (audio, video, data, or combo) calls via buddy list

No from VSX / Yes from MMPCC (VSX can be a

buddy)

Able to initiate multipoint (audio, video, data, or combo) calls via buddy list No

All Meeting Rooms could be made to appear in

global buddy list Able to switch between IM,

audio, and video during call No Call Initiation, Directory Services, & Video Telephony

Unified Device Appearance' --- Video add - dial with phone and click to add video if available on both sides. Single number for voice and video (same as unified device appearance above) No

Browse phone directory via video endpoint user interface and then click to call No

Enter 4 or 5 digit extension (internal), 10 digit number (external), or SIP URL. See dial-through gateway. Yes (non-gateway calls)

Hold - put another endpoint, MCU, or gateway on hold

No from VSX / Yes from MMPCC

Music on hold

No from VSX / Yes from MMPCC

Transfer - a call to another audio or video endpoint, MCU, or gateway on hold


Nortel Networks 51

Forward - a call to another audio or video endpoint

No from VSX (although MCS profile could

accessed via web browser) / Yes from MMPCC

Pickup - a parked call No from VSX / Yes from

MMPCC

Park No from VSX / Yes from

MMPCC Multiple lines No Hunt group - call routed to

next available line in queue No No

Audio voicemail for video calls that are not picked up

No from VSX (although MCS profile could

accessed via web browser) / Yes from MMPCC

Automatic redirect of failed call to Help Desk

XML services No Ad Hoc Multipoint ‘Classic’ ad-hoc – point-to-

point call extended to multipoint by using ‘conference’ button on device (video or audio) to add additional participants sequentially (video or audio). Highly related to buddy-list based ----- see IM & Presence above

Yes MAS (DIVX only) / No MGC No

Buddy list-based ---- see IM & Presence above

Meet Me Multipoint & Scheduling Meet-Me entry-queue =

using DTMF endpoints can enter to desired predefined meeting room Yes MAS / Yes MGC

Direct dial in = endpoints can dial in to pre-defined conference number (either scheduled or static Meeting Room)

Scheduling tool for video conferences No No

Direct dial out ---- need scheduling tool see above No No

Management Integrated management

tools Yes No Integrated billing for voice

and video calls Yes No Separate, centrally

managed bandwidth policies for voice and video No No

Central management of dial restrictions (inter-site vs. intra-site, room vs. desktop) No No


Nortel Networks 52

Automatic rerouting over gateway (ISDN/PSTN) if network resources not sufficient No No

Least cost routing (IP to edge, then ISDN) Yes No

NAT/firewall traversall

Support on MGC and VSX Yes No Dial Through Gateway

SIP to H.323 or H.320 No No Video Extensions Far end camera control No No

H.239 People & Content No No Fast update No No Frame rate No No

Frame resolution No No

Table 6 Feature Matrix


Nortel Networks 53

12. Appendix B – Acronyms AES Advanced Encryption Standard

ALG Application Level Gateway

AMR-WB Adaptive Milti-Rate WideBand

ANSI American Standards Institute

ATSC Advanced Television Systems Committee

CELP Code Excited Linear Prediction

CIF Common Interchange Format

CODEC Encoder/Decoder

CS-ACELP Conjugate-Structure Algebraic CELP

DSCP Differential Services Code Point

FW Firewall

ISDN Integrated Services Digital Network

ITU International Telecommunications Union

LD-CELP Low Delay CELP

MAS Media Application Server

MCS Multimedia Communication Server

MCP Multimedia Communications Platform

MCU Multipoint Conferencing Unit

MGC Multipoint Gateway Controller

MMPC Multimedia Personal Computer

MPEG Motion Pictures Experts Group

NAT/NAPT Network Address Translation/ Network Address Port Translation

PCM Pulse Coded Modulation

PHB Per Hop Behavior

PRD Product Requirements Document

QCIF Quarter Common Interchange Format

QoE Quality of Experience

QoS Quality of Service

RTP Real-Time Transport Protocol

RTCP Real-Time Transport Control Protocol

SIP Session Initiation Protocol

SVZ Secure VoIP Zone

TCP Transmission Control Protocol

UDP User Datagram Protocol

VCEG Video Coding Experts Group

VoIP Voice over IP

VPN Virtual Private Network


Nortel Networks 54


Nortel Networks 55

Contact Us: For product support and sales information, visit the Nortel Networks website at:

http://www.nortelnetworks.com

In North America, dial toll-free 1-800-4Nortel, outside North America, dial 987-288-3700.

Copyright © 2004 Nortel Networks All rights reserved. March 2004 The information in this document is subject to change without notice. The statements, configurations, technical data, and recommendations in this document are believed to be accurate and reliable, but are presented without express or implied warranty. Users must take full responsibility for their applications of any products specified in this document. The information in this document is proprietary to Nortel Networks Inc. The software described in this document is furnished under a license agreement and may be used only in accordance with the terms of that license. Trademarks Nortel Networks, the Nortel Networks logo, the Globemark, Unified Networks, and PASSPORT are trademarks of Nortel Networks. Adobe and Acrobat Reader are trademarks of Adobe Systems Incorporate. All other Trademarks are the property of their respective owners.

solution guide for video conferencing rel1dot2€¦ · solutions guide for: video conferencing...

Documents