Download IOCOM Whitepaper:

IOCOM Whitepaper:
Scalability, Redundancy, and Network Efficiency
September 2008
IOCOM • www.IOCOM.com • 312-786-9169
Table of Contents
1.
Executive Summary
2.
Introduction
3.
Single Server Deployment
4.
Small Grid Server Deployment
5.
Large Grid Server Deployment
6.
Federation
7.
Conclusion
8.
Appendices
I. Server Specifications
II. Setting Up the Server
III. Bandwidth Calculations
IV. Estimated User-To-Server Table
Executive Summary
The IOCOM Grid (IG) multimedia collaboration platform
is a scalable, adaptable, software solution enabling geographically distant users to easily and reliably meet faceto-face in rich collaboration environments. The IG software platform is an IP network based client and server
application. The IG Unified Collaboration Server (UCS)
runs on commodity hardware running the Linux operating system. The grid architecture can be readily scaled
across commodity hardware to increase capacity while
functioning as a single centralized system. The IG UCS
can also be federated with additional IG UCS systems to
expand the network within or outside of internal firewalls.
This document details the IOCOM server architecture
with emphasis on scalability, redundancy, and network
efficiency.
Introduction
IOCOM takes a fundamentally different approach to
multi-point visual communication. Whereas traditional
approaches mix multipoint video into a combined stream
the IG manages each video stream independently. The
IG Multiple Stream Client/Server thus has a number of
unique advantages over traditional approaches:
Telepresence. The market for high end multi-codec
rooms has dramatically grown over the past
few years, IOCOM overall architecture allows
telepresence experience at a fraction of the
cost of other telepresence systems while connecting to laptop and mobile computing devices.
Integration. True audio, video, data integration in
the same application, with a consistent interface, whether on a PC, laptop, or in a conference room, running over any standard network.
Inclusiveness. Software and/or web-browser
based interface makes it easy to bring in additional people for multipoint conferences with
minimal setup, little expense, and no lost time.
Furthermore, traditional approaches like video conferencing hardware present the following challenges:
Closed systems. The proprietary hardware and
software requirements of traditional conferencing systems results in:

Increased support costs, requiring
specially trained technicians

Extremely high costs for redundancy and backups

Inconsistent user interfaces and
product features, requiring additional user training for each device
Reliability. Peer-to-peer approaches are unreliable, plagued by broken or degraded connections, no central management, billing
procedures, QOS, or SLA’s.
Limitation of experience. Most conferencing
tools are only able to send and receive one
video stream. This severely limits inclusiveness, efficiency, reach, and user experience.
Through the use of Grid computing and IOCOM's
unique federation approach to stream management,
the IG overcomes the challenges preventing other
client/server applications from scaling. The IOCOM
network servers can be deployed in a variety of
ways, scaling from a single stand alone Unified Collaboration Server (UCS) to a federated, large grid
deployment. This scalable, redundant, and flexible
design gives any size organization or service provider the tools it needs to meet all of their visual communication needs.
Single Server Deployment
The core strength of the IG platform is the ability to
run on a single server running the IOCOM Unified
Collaboration Server software (see Appendix 1 for
current UCS hardware/software specifications) . In
such deployments, all endpoints authenticate to the
single server (UCS), which bridges all audio, video,
and data traffic. The UCS is easily installed on all
standard networks (see Appendix 2) and is responsible for:

Bridging

Signaling .

Managing Media Streams

Audio Compositing

Presence Management

Meeting Recorder

Web Conferencing

H.323/SIP Transcoding/Interoperation

Usage Statistics Manager

Administrative Monitor
All of these functions can run concurrently on a sin-
A standard IOCOM UCS license supports up to 100
registered users with 10 concurrent IG clients and 10
concurrent web clients. A physical server can support
2 licenses for a total of 200 register users with 20/20
concurrent IG/Web client users.
Small Grid Server Deployment
The IOCOM server platform is designed to scale upward into grid deployments. In a small grid deployment,
additional UCS systems can be added to balance the
load and expand the user base. The grid provides redundancy. In the event of a failed server, the processes
will be redistributed to another server in the grid.
gle server. In grid deployments, the processes are
load balanced across multiple server.
Bridging manages the signaling between clients and
other servers in the grid. Bridging functions also include routing media streams through the UCS/grid to
provide ultimate reliability and the flexibility of independent streams. Media is managed at the server
level to ensure efficient bandwidth allocation (e.g.
when one site turns off a video stream, the stream is
no longer sent from the server to that site thus conserving bandwidth).
The Presence Manager maintains the master presence list of users connected to the IOCOM Grid, reflected in the Invite list at the end user, thus allowing
for users to see who among their contacts is online
and invite them directly into a meeting.
The Meeting Recorder allows authorized users to
record meetings with full audio/video/data for playback at a later time.
Web Conferencing powers a set of collaborative
tools, including Chat, Whiteboard, File Transfer, and
shared Web Browsing.
The H.323/SIP features on the UCS allow for interoperation with these protocols.
Finally, the server stores meeting detail records
which include meeting participants, duration, bandwidth usage and details on collaborative tool usage
(such as Chat, File Transfer etc.). The Administrative
Monitor tracks server utilization such as CPU, network usage, and memory usage.
In a Small Grid Deployment, all UCS systems continue
to perform all UCS tasks:

Bridging

Signaling

Managing Media Streams

Audio Compositing

Presence Management

Meeting Recorder

Web Conferencing

H.323/SIP Transcoding/Interoperation

Usage Statistics Manager

Administrative Monitor
The resource load balances across all servers equally.
The number of registered users and concurrent usage
is determined by the number of servers in the grid.
Please reference Appendix 4 for a User-to-Server table.
Large Grid Server Deployment
In a large grid deployment, two servers are set as designated entry points into the grid . The designated entry
point servers distribute the workload to the remainder
of the servers in the grid, which balance the load
equally. The grid provides redundancy. In the event of
a failed server, the processes will be redistributed to
another servers in the grid.
As large grid deployments scale, the entry point servers
By using the UCS system or UCS Grid in a regional data
center, traffic is localized and traffic efficiency optimized.
Only one copy of video streams is sent between grids.
Also, if no clients from a remote grid are viewing a video
stream then the stream is not transmitted to the remote
grid,. Instructions for setting up UCS system or UCS
Grid Federation has been included in Appendix 5.
can distribute processes to secondary workload distribution servers that then distribute the workload
throughout their sub-section of the servers in the grid,
which then balance the distributed load equally.
Federation
Any of the above deployment scenarios can be federated across networks or data centers. Federated UCS
systems or Server Grids allow for scaling across multiple data centers. Federated grids transparently share
user presence information. All audio/video/data
streams are routed from the clients through the local
UCS/grid to the remote UCS/grid and then down to the
remote client endpoint.
Conclusion
The IOCOM Grid delivers a complete communication
solution. Through the unique, flexible architecture of the
IOCOM UCS and UCS Grid, companies can scale their
solution to fit their needs, their resources, and the size of
their organization. The IG software or web-browser
based interface provides secure, full-featured visual
communication for everyone in your company, without
the expense and limitations of traditional approaches to
video conferencing and without having to worry about
scaling your solution as your company grows and
changes.
Appendices
Appendix 1: Server Specifications
CPU: Single Quad-Core IntelR XeonR or Single IntelR CoreTM 2 DuoR
RAM: 2 Gigs of RAM or 1 Gig of RAM (At Least)
Hard Disk: We recommend setting up at least a RAID 1 (Mirror) but our server software does not require it. But we
do recommend a consider sized drive for UCS recordings. Meeting recording are generally large sized files.
Network: 100Mbs NICs and Uplinks (Server NICs should always be set to Full-Duplex and network uplinks to UCS
server should always support no less than 100Mbs.
Server OS: RedHat Version 4 Update 6 (I've included a text file which lists the required rpm packages to be installed
in order for our UCS server software to function properly.)
Backups: We have a backup utility "igbackup" which you can create backups of your ucs database as well as your
license file. These backups are saved to /root on your server. We recommend that you store these backups to an
offsite server or location. Again recommended but not required!
Appendix 2: Setting up the Server
Our Redhat iso's can be downloaded from: http://customer.insors.net/ig-isos/
The require iso's files to perform a basic install are:
IG-RHEL4.6-i386-ES-disc1.iso
RHEL4.6-i386-ES-disc2.iso
RHEL4.6-i386-ES-disc3.iso
RHEL4.6-i386-ES-disc4.iso
Here are some simple instructions on using our kickstart file from our iso images to install RHEL:
1. At boot: prompt type the following command:
linux ks=cdrom:/ks.cfg
2. If prompted to specify source media location, select CDROM.
Install will proceed and likewise prompt you to insert others discs
along the way. Insert appropriate discs when prompted. After install
completes, you should be able to log into the system with the default
root password. Once the new OS has been fully installed you can log into
the box with the following root passwd: insors#4ucs
UCS Server Software
After the OS installation is complete, install the same version of the
UCS software release that you installed previously on this UCS.
Download the lastest server release from the following URL: http://release.insors.net/ucs
iocom-ucg-installer-RHEL-{20080726 or greater}.tgz
Now, we can unzip the the new server release with the following command and proceed with the UCS installation:
[root@ucs ~]# tar -zxvf /root/iocom-ucg-installer-RHEL-{20080726 or greater}.tgz
Install the UCS software by entering the following: [root@ucs ~]# sh /root/iocom-ucg-installer-RHEL-{20080726 or
greater}/setup.sh
Answer NO when you are prompted to specify a license key during the UCS installation process.
Configure UCS Networking via IGNETCONFIG
UCS networking via our ignetconfig utility: /var/www/html/iocom_ucs/manage/utilities/ignetconfig
We'll need the following information before we continue with this utility:
Server Hostname
Server IP Address
Server Netmask
Server Gateway
DNS Server/Servers your UCS will use
Enter the command: [root@ucs ~]# ignetconfig
This is an IOCOM utility to change the IP address and hostname of your server.
Do you wish to continue? [no] yes
This server is running: Red Hat Enterprise Linux ES release 4 (Nahant Update 6)
Enter this server's hostname (e.g. server.company.com): {SERVER_HOSTNAME}
Resolving {SERVER_HOSTNAME}...
The host name you entered resolves to: XXX.XXX.XXX.XXX
Do you want to use this address for this host? [yes]
Enter the NETMASK for this server: XXX.XXX.XXX.XXX
The gateway for this network would typically be: XXX.XXX.XXX.XXX
Do you want to use this gateway address for this system? [yes]
Do you want to use the default name servers (4.2.2.6, 209.244.0.4)?
[yes]: NO
WARNING: you may lose your SSH network connection if you apply these
changes!
Do you want to APPLY your changes and restart networking? [no] : yes
License UCS Server
Now you can license your server. You'll need to obtain a license number from [email protected]. Once you've
obtained a valid ucs license you can install it via our iglicense utility on your ucs.
Enter the following command: [root@ucs ~]# iglicense
iglicense : 6.0.080729 - Jul 29 2008 - 18:40:35
Licensing System Server ID: XXX.XXX.XXX.XXX,XX:XX:XX:XX:XX:XX
Enter your license key: {ENTER LICENSE HERE}
Restart the UCS by entering the following: [root@ucs ~]# service igmaster restart
Configure UCS via web frontend
You can configure your ucs via our php web frontend at: http://{usc_ip or ucs_hostname}/manage
The default login information is:
User: igadmin
Pass: igcmgr01
Once you accessed the /manage page you see several sections that are self-explanatory:
User Manager
Manage UCS Users
Room Manager
Manage UCS Meeting Rooms
Limits Manager
Configure UCS and Set Meeting Limits
Federation Manager
Configure UCS Federation
Gateway Manager
Configure UCS Gateways
Client Software
Manage the Client Software Download Area
Usage Viewer
Review Meeting Usage
Call Detail Viewer
Review Gateway Usage
Server Graphs
Review Server Usage Graphs
Version Manager
UCS Executable Versions
Service Manager
UCS Service Status and Control
Diagnostics
UCS Diagnostics Page
The Service Manager will allow you to restart specific nodes of the UCS as well as restart the igmaster (all nodes).
The Gateway Manager allows you to allow add a SIP, H323, or IAX trunk to your UCS.
How to Perform an IG Backup
From a shell on your UCS server you'll to run the following command: [root@ucs ~]# igbackup
The backup file will be copied to your ucs server /root directory. The file is usually named: {ucs_hostname}_IG_
{current_date}.tgz
The included backed up files are:
/version.txt
/images/
/images/calendar.png
/email.png
/images/cal.gif
/images/iocom_logo-sm.png
/images/iocom_logo.png
/ucsdb/
/ucsdb/config.xml
/ucsdb/insors.db
/insors.lic
/venue/
/venue/manual.php
/venue/igpix
/venue/index.php
/venue/images
/venue/novenue.html
/venue/venue.cgi
/venue/venue_header.html
/venue/manage
/venue/venue_footer.html
/igdiags.txt
/igmeeting.log
Appendix 3: Bandwidth Calculations
Assumptions:
The following assumptions will be made for calculating bandwidth over 3 scenarios

Each camera is set to H.264 medium using a maximum of 256 Kbps of bandwidth. This is a worst case as
actual bandwidth usage will be lower and varies based on movement within the video image.

Audio is set to “standard” which uses 64 Kbps of bandwidth

IP headers for audio streams are assumed to consume 36 Kbps of bandwidth.

IGPix is assumed to consume 20 Kbps of bandwidth

Conference Room A is simultaneously transmitting 2 PTZ cameras views

Desktops endpoints are transmitting one USB video image

Upstream and downstream bandwidth numbers are shown for reference in asymmetric networks.

The UCS is on a symmetrical IP connection and the total bandwidth required number is the greater of the
upstream and downstream usage.
Conference Room = 632 Kbps Upstream
Stream
Qty
Bandwidth Per
Extended
Video – H.264 medium
2
256 Kbps
512 Kbps
Audio
1
64 Kbps
64 Kbps
IP Headers
1
36 Kbps
36 Kbps
IGPIX
1
20 Kbps
20 Kbps
Total
632 Kbps
Desktop System = 376 Kbps Upstream
Stream
Qty
Bandwidth Per
Extended
Video – H.264 medium
1
256 Kbps
256 Kbps
Audio
1
64 Kbps
64 Kbps
IP Headers
1
36 Kbps
36 Kbps
IGPIX
1
20 Kbps
20 Kbps
Total
376 Kbps
Scenario 1: Two desktops in a meeting (Kbps)
Upstream
Downstream
Total
Desktop 1
376
376
376
Desktop 2
376
376
376
UCS
752
752
752
This connection would require 376Kbps of bandwidth for each desktop endpoint and 752Kbps for the UCS.
Scenario 2: Three Desktops in the same meeting (Kbps)
Assumes each endpoint views both remote video views.
Upstream
Downstream
Total
Desktop 1
376
632
632
Desktop 2
376
632
632
Desktop 3
376
632
632
UCS
1128
1896
1896
The down stream bandwidth for each endpoint is increased by the additional video image (632 = 376 + 256).
Scenario 3: Conference A and three desktops
Assumes each endpoint views all video images
Upstream
Downstream
Total
Desktop 1
376
1144
1144
Desktop 2
376
1144
1144
Desktop 3
376
1114
1144
Conference Rm A
632
888
888
UCS
1760
4320
4320
The downstream bandwidth for each desktop increases by 512 Kbps to account for the two additional video views
from the conference room. This scenario assumes that each desktop would be viewing 4 remote images. (Local images are still displayed but do not use bandwidth) The conference room would only be viewing 3 remote desktop images, therefore it’s downstream usage would be 888 Kbps, (888 = 1114 -256)
Scenario 4: Conference A and three desktops – Selected Video
Assumes that the first desktop is viewing one of the four available video images, the second desktop is viewing two
video images, and the Conference Room and third desktop are viewing all available images.
Upstream
Downstream
Total
Desktop 1 (view 1 video images)
376
376
376
Desktop 2 (view 2 video images)
376
632
632
Desktop 3 (view all 4 video images)
376
1114
1114
Conference Rm A (view all 3 remote videos)
632
888
888
UCS
1760
3010
3010
Appendix 4: Estimated User-to-Server Table
# of
Users
100
500
2000
5000
10000
20000
50000
100000
500000
# of
servers
1
2
7
16
32
63
157
313
1563
# of Infrastructure
Servers
1
1
1
2
4
7
17
35
178
Total
Servers
2
3
8
18
36
70
174
348
1741