Interconference Room Video Communications System

Project Plan

TeamMay 03-13

Date of SubmissionTuesday, September 24th, 2002

ClientSenior Design

Faculty AdvisorS.S. Venkata

ECpE Department Chair

Team MembersNoah Korba

Brian MarshallNick McInerney

Jalal Saidi Melissa Weverka

Table of Contents

1 INTRODUCTORY MATERIALS...........................5

1.1 ABSTRACT........................................................................................................51.2 DEFINITION OF TERMS...............................................................................5

2 PROJECT PLAN.........................................................................9

2.1 INTRODUCTION.............................................................................................92.1.1 General Background..............................................................................92.1.2 Technical Problem..................................................................................92.1.3 Operating Environment.........................................................................92.1.4 Intended Users and Uses.......................................................................92.1.5 Assumptions and Limitations.............................................................10

2.2 DESIGN REQUIREMENTS........................................................................102.2.1 Design Objectives......................................................................................102.2.2 Functional Requirements...........................................................................112.2.3 Design Constraints....................................................................................112.2.4 Measurable Milestones..............................................................................12

2.3 END-PRODUCT DESCRIPTION..............................................................122.4 APPROACH AND DESIGN.......................................................................12

2.4.1 Technical Approaches.........................................................................122.4.2 Technical Design...................................................................................132.4.3 Testing Description..............................................................................142.4.4 Risks/Risk Management.......................................................................14

2.5 FINANCIAL BUDGET................................................................................152.6 PERSONAL EFFORT BUDGET...............................................................152.7 PROJECT SCHEDULE.................................................................................15

3 CLOSURE MATERIAL....................................................17

3.1 PROJECT TEAM INFORMATION..............................................................173.2 Summary.......................................................................................................18

List of Figures

Figure 1: A diagram of our system....................................................................................11Figure 2: Project Schedule.................................................................................................16

List of Tables

Table 1: Financial Budget..................................................................................................15Table 2 : Personal Effort Budget.......................................................................................15

Introductory Materials

1.1 AbstractMany large organizations are incorporating telecommunications into their everyday routine. To make this technology available to smaller institutions, a low cost multi-conference room video-communications system will be created. To accomplish this, the system will be Internet-based, and provide two-way audio and video streaming. This design allows information to be presented around the world.

1.2 Definition of Terms

Asymmetric Key Encryption – AKE is usually known as Public/Private Key Encryption. The most famous, RSA, is one of the worlds strongest overall encryption methods. AKE involves choosing a strength (“bit strength”), and producing a set of keys. (which are then owned by the key set owner) The public key is made available to anyone who wishes to send you encrypted data. The data is run through the public key, and then transmitted to the key set owner. The data then is decrypted using the private key, made available only to the key set owner. The only way to decrypt this data is to own (or forcefully generate) the private key. For comparison, a 56-bit RSA key using the RC-5 algorithm has a possibility of 72 quadrillion combinations, and takes (using parallel processing) about 100 days to crack.

Audio Capture Device – A device attached to the computer, usually plugged into the PCI bus on a computer, which converts sound patterns into Raw Audio Data. Usually dubbed a “Sound Card”.

CODEC – See both Compression and Decompression

Compression – The “CO” in CODEC, compression is the method of representing a piece data in a smaller size. In the early days of computing, compression was limited to general algorithms designed to shrink the size of raw, random data. In recent years, compression has become specific, from Audio/Video Compression (such as DiVX ;) or MPEG-3) to Textual-Based Compression. These newer compression methods use a combination of shifting-frame pattern recognition and data removal to shrink the size of data - without sacrificing quality. Most compression utilities can be configured to favor a smaller size over data quality and vice versa.

Decompression – The “DEC” in CODEC, decompression is the method of recreating raw data from a compressed piece of data. The primary job of the decompression portion is to detect the style of compression used on a file, and

produce raw data, in the best form as possible. Many decompression algorithms implore decompression and best-guess techniques to predict and reproduce data as close to the original as possible.

Decryption – The process of revealing concealed (“encrypted”) data with the proper authorization.

Demultiplexing – The process of taking a multiplexed stream of data, and splitting it back into its original individual parts.

Encryption – The process of concealing data in an unreadable form, unless proper authorization is possessed to view (“decrypt”) the data.

MCP – Acronym for motion controlled platform

Multiplexing – The process of taking individual data streams and combining them into one single data stream. Also called a multiplexed stream.

Raw Audio Data – The format of data in which standard audio generation can be applied to, to produce audible sounds through the users output device. For example, Compressed Audio Data (such as MPG – MPEG3 Compression) cannot be heard unless it is decompressed into Raw Audio Data. Only then can it be successfully heard on the users audio output device.

Raw Video Data – The format of data in which standard graphical rendering can be applied to, to produce full-motion video on the users computer screen. For example, Compressed Video Data (such as DiVX ;) – MPEG-4 Compression) cannot be displayed unless it is decompressed it into Raw Video Data. Only then can it be successfully rendered on the users video output device.

RPC – Remote Participant Control

Socket – When someone says socket, they are usually using it in reference to Berkeley Sockets – a programming interface for communications over the Internet. Implementations of Berkeley Sockets are used on virtually all operating systems, from UNIX (IO-Socket libraries) to Windows (WinSock). They provide a seamless way for programmers to create network applications. Older UNIX implementations contained three states – Raw (on top of IP), TCP/IP and UDP/IP. Most implementations now provide access to only UDP/IP and TCP/IP sockets. Sockets allow one to create both clients and servers for network communications.

TCP – TCP stands for Transmission Control Protocol. Most noted as being the Internet Protocol, TCP was established in the late 1970’s to provide reliable communications over packet-switched networks. Unlike its sibling UDP, TCP provides a three-way handshake to ensure a solid connection between two computers. TCP also ensures packet transmission success by providing a CRC

(cyclical redundancy check) at the end of the packet to determine if, during its course of broadcast, the packet is corrupt. If so, TCP has built in send/resend as well as flow control to ensure the packet arrives safely and unharmed. If the physical connection causes the non-transmission of packets (a break in the line, for instance), TCP will “timeout” on the connection, and return an error to the user. Most application layer protocols (such as Telnet, FTP, HTTP and SSH) use TCP as their primary transport method.

Stream, Streaming – The word “stream” is used for many different applications. Most notably, socket communications over the Internet are called “streaming” since they move data from one point to another constantly, like a river. Streams can also be referenced to raw unprocessed data, which usually comes directly from a socket buffer.

Symmetric Key Encryption – SKE involves the process of “secret key” encryption and decryption. Unlike AKE, where everyone can know your public key, SKE keys must be held by only those involved in the data exchange. SKE’s are often a one-to-one key. The most basic SKE was invented by Julius Caesar. This cipher (known as the Caesar Cipher) was based off of the equation E=((N+K) modulus 26), where N is the numerical representation of a letter (A=1, B=2, etc), and K is the modifier. The modulus 26 is to ensure the numerical character range stays between 1 and 26 (A and Z).

Synchronized Multimedia Stream – A synchronized multimedia stream is exactly what it implies – a stream of data in which video is matched up to its corresponding audio. This stream will eventually be split apart by the same means. For example, if you did not convert your multimedia stream to a synchronized multimedia stream, video of you talking may not match up to the corresponding audio. In Hollywood, this is called “bad dubbing”.

TCP – TCP stands for Transmission Control Protocol. Most noted as being the Internet Protocol, TCP was established in the late 1970’s to provide reliable communications over packet-switched networks. Unlike its sibling UDP, TCP provides a three-way handshake to ensure a solid connection between two computers. TCP also ensures packet transmission success by providing a CRC (cyclical redundancy check) at the end of the packet to determine if, during its course of broadcast, the packet is corrupt. If so, TCP has built in send/resend as well as flow control to ensure the packet arrives safely and unharmed. If the physical connection causes the non-transmission of packets (a break in the line, for instance), TCP will “timeout” on the connection, and return an error to the user. Most application layer protocols (such as Telnet, FTP, HTTP and SSH) use TCP as their primary transport method.

UDP – UDP stands for User Datagram Protocol. Sibling to TCP, UDP provides connectionless communications, providing no guarantee of data delivery or integrity. UDP does not support “timeout”, so it is the sole responsibility of the

programmer to determine when a set amount of time has passed to call a connection “dead”. UDP is most often used when the overhead of a TCP connection is too much for the connection needed. UDP is most often used for streaming audio and video applications, where error correction and packet retransmission are detriments to overall performance. A handful of application-layer protocols use UDP (DNS, older versions of RealAudio and Shoutcast) as transport methods. Most programs that require the functionality of UDP for “streaming” implementations are now moving to the Multicast Standard.

USB – Acronym for Universal Serial Bus

Video Capture Device – A device attached to the computer, usually plugged into the USB (Universal Serial Bus) port on a computer, that converts light patterns into Raw Video Data.

Visual Aid – Any format of a graphic that will illustrate what a speaker is attempting to communicate. Ex. Whiteboard drawings, notes on a piece of paper.

1 Project Plan

2.1 Introduction

2.1.1 General BackgroundThe Interconference room visual communication system’s objective is to create a low cost alternative to current telecommunication technology. To keep this system low cost, some traditional features were modified to make the system more cost effective while maintaining a relatively high level of quality. For example, the Internet will be used as the communication medium, since it is free, and already established. Also, the rooms will be limited in size to reduce the cost of equipment. Finally, the system will be portable so it can be shared between many people in the institution.

2.1.2 Technical ProblemIn order to make the system efficient, the project will be split up into two different segments – the hardware segment and the software segment.

HardwareThe hardware segment consists mainly of creating, buying and testing the hardware that will interface with the rest of the system. It will also involve creating drivers to interface those hardware devices with the software portion of the project.

SoftwareThe software segment consists of writing a Graphical User Interface, implementing CODECs for audio, video and data compression, creating an encryption and decryption engine for the system, and providing seamless integration with the ever-changing technology existing on the Internet.

2.1.3 Operating EnvironmentThe software will be written for the Microsoft Windows family of operating systems. The hardware will be used indoors, but will need to be slightly durable, since it is portable.

2.1.4 Intended Users and UsesThe intended users of the multimedia conference system are those who need to conduct meetings with others who are not in the immediate area, or cannot attend a meeting in person. It is designed for both the novice and expert computer user -

providing an easy to understand interface for the beginner, along with the ability to control virtually all aspects of the system for the computer guru.

2.1.5 Assumptions and LimitationsSeveral assumptions have been made for this project. This project also entails limitations as well. The assumptions and limitations are defined below:

Assumptions Conference rooms will be small in size There will be only two rooms in communication with each other Each room will contain a maximum of five participants

Limitations Internet Bandwidth Maximum CPU processing power Compression strength

2.2 Design Requirements 2.2.1 Design Objectives

The project has been broken down into the objectives listed below.

Display multimedia on both participants screensBoth conference rooms will be able to see the remote video, as well as hear remote audio.

Compressed and Encrypted video and audio streamsThe system will use various audio, video and data compression techniques to condense the audio/video streams, to conserve both participants bandwidth. The system shall also use an optional medium-strength Asymmetric Key encryption technique to provide data security- so that only the authorized participants are allowed to view the audio/video stream.

Motion Controlled Platform (MCP)A platform will be created in which a camera could be mounted on. This will allow the camera to be moved both up and down and right to left.

Figure 1: A diagram of our system

2.2.2 Functional RequirementsThe following defines the functional requirements the end product will perform.

All participants can operate the system The system will be designed to provide ease of both setup and use, so that participants with a wide knowledge of computers can operate the system.

Participants can choose to enable encryption and/or compressionThe system shall allow the participants to turn on or off both compression and encryption, to increase transmission performance, or save on CPU cycles.

Local Camera ControlThe system shall give each participant local control over their camera, to focus the camera on a specific person, or all of the participants.

PortabilityThe system can be easily moved and set up in different conference rooms.

2.2.3 Design ConstraintsThis section defines constraints considered during the design and implementation of the project. Cost

The system must be low cost while maintaining its functionality.

Local Internet bandwidthSince video will be streaming over the Internet, there must be sufficient bandwidth to view real time video at all client computers.

CPU processing powerThe server must composite and stream real time audio and video, as well as process multiple incoming audio streams. This will require significant CPU power.

2.2.4 Measurable MilestonesThe following lists the measurable milestones of the project.

Project scope and intended features defined (5%)Features for the completed system are defined that would create a complete and usable product.

All subsystems’ functionalities and interfaces designed (20%)All subsystems can be implemented using the documented subsystem description and interfaces.

All subsystems function properly under controlled conditions (30%)Using test inputs, all subsystems pass limited tests and can produce expected output for all features, even if under controlled inputs.

All subsystems function properly under all conditions (20%)Using test inputs, all subsystems will work under all foreseeable conditions and produce expected outputs.

Complete system operates under controlled conditions (15%)Using completed subsystems, the final product can be assembled, and produce expected outputs under controlled conditions.

Complete system operates under all conditions (10%)The completed system will operate in a useable state, with no known errors.

2.3 End-Product Description The system will connect two small conference rooms with a small number of participants per room. It will broadcast both audio and video from one room to another using the Internet. The cameras will be mounted on a motion-controlled platform, which allows them to be focused on individual speakers, as well as the entire group. The system will be easily portable from one room to another, allowing many people to utilize one system.

2.4 Approach and Design

2.4.1 Technical ApproachesThis system will be composed of a software subsystem and a hardware subsystem. The following lists the different approaches that will be considered for the design phase of the project.

Software

The software segment of this system can be approached several ways. The various software components can be seen as self-contained modules that will communicate through an external language such as TCP/IP or pipes, or it can be seen as one module with different components like DLL’s or classes. The network communication can be seen one of two ways as well. It can be approached as a client-server model, or a peer-to-peer model.

Hardware Motion Controlled Platform (MCP) There are several ways in which MCP could be designed. The MCP can be controlled using an X-Y axis location process with a joystick or similar device. It could also be preprogrammed to move to specific positions in the conference room, focusing on a specific area, rather than a panoramic view of the entire room.

Loud Speakers Self-amplified computer speakers could be used or an amplified version of a stereo speaker via a receiver could be implemented.

2.4.2 Technical DesignSoftware

Server modelThe two conference rooms will each have a computer that will run the audio and video feeds. These computers can talk to each other as peers, or one can establish itself as a server to set conference properties such as encryption strength and compression type.

Compression/EncryptionThe conference can be encrypted and compressed. There are numerous different algorithms to accomplish these tasks. Either one algorithm for each category will be used, or several will be available to the user to choose. The user will have the option to turn off encryption, since it will produce additional CPU strain.

Video CaptureThe video from the cameras will need to be captured into a raw digital video format. Depending on the camera used, this can be done by writing an interface driver for a digital camera, or writing an interface driver for a video capture card.

Audio Capture

The audio for each conference room will be input to the computer through the sound card, so the raw audio will need to be extracted either from the operating system, or the sound card itself.

Hardware

Audio systemThe microphone will handle transmission of audio signals from one location to another. The quality of the microphones needs to be such that the remote participants can understand the conversation. The audio speakers will amplify audio signals from remote site. The audio speakers can be amplified so that all local participants can hear the conversation.

.Video System

The USB digital camera will record visual movements of the participants.The MCP will allow the USB digital camera to be moved to various positions. The MCP needs to be easily controlled by all local participants via a remote control device.

.

2.4.3 Testing DescriptionThe system will be tested in phases. Each subsystem will be tested using a white box testing model by it’s designer to eliminate any obvious errors, and ensure that all desired functionality is present. Any errors found errors will then be corrected and the subsystem will be black box tested by a third party to ensure that it will work under all circumstances. Any errors will be corrected, and the subsystem will then be available for incorporation by the complete system.

After the subsystems have been shown to be free from errors, the complete system will be assembled and white box tested, and all features will be verified for proper functionality and usability. Any visible errors will be corrected, and the entire system will be black box tested by a third party. Any remaining errors will be fixed to produce an error free final product.

2.4.4 Risks/Risk Management Team members might leave group

For various reasons team members may be forced to quit the project. To cope with this problem, we will make sure that every task can be performed by at least two team members.

Cannot get parts on timeThere may be a problem obtaining parts in a timely fashion. To minimize this risk, the parts will be ordered as soon as possible from a reputable company

2.5 Financial Budget Table 1 contains detailed financial estimates for the project.

Table 1: Financial Budget

Item Original Estimated CostPoster $50USB Digital Cameras $150Microphones $20Parts $30Total Estimated Cost $250

2.6 Personal Effort Budget

Table 2 contains detailed time estimates for the project.

Table 2 : Personal Effort Budget

 Noah Korba

Nick McInerney

Brian Marshall

Jalal Saidi

Melissa Weverka

Total Team Effort

Develop Project Plan 6 5 8 0 5 24Develop Project Poster 13 13 13 0 15 54Develop Project Design 33 30 27 0 29 119Implement Project Design 61 65 50 0 61 237Develop Final Report and Presentation 6 8 6 0 8 28Total Estimated Effort 113 113 98 0 110 434

2.7 Project Schedule

Figure 2: Project Schedule

3 Closure Material3.1 Project Team Information

Team MembersNoah Korba2724 Stange Ave. #3Ames, IA 50010(515) 451-6125nkorba@iastate.eduCpE

Nick McInerney425 15th St.Ames, IA 50010(515) 232-2131nmcinern@iastate.eduEE

Brian Marshall5521 Friley NilesfosterAmes, IA 50012(515) 572-5090bmarshal@iastate.eduCpE

Jalal Saidi3414 Orien Dr. #140Ames, IA 50010(515) 232-9930saidij@iastate.eduCpE

Melissa Weverka1233 Frederiksen Ct.Ames, IA 50010(515) 572-7693mweverka@iastate.eduEE

3.2 Summar y Upon completion of this project, the cost efficient video conferencing system utilized all the needs of both the presenter and the active listening audience. This system was not only less expensive than some of its predecessors, but actually had some unique features like the remote users ability to change or modify the presenters notes or having the presenters screen indicate a message window when a concept is questioned by either the remote user or audience member. The designed video conferencing system met or exceeded its goals in a timely fashion due to the unlimited knowledge and experience from the participating group in this project.