Camera Control Video Surveillance rftg.development.googlepages.com Creation Date: January 20, 2008 Version: v0.

10 - 5/MAI/2008 Author: Ricardo Fili pe Teixeira Gomes DISCLAIMER This document was prepared by Ricardo Filipe Teixeira Gomes, who reserve all rig hts. © 2008 Ricardo Filipe Teixeira Gomes This document is available for consult ation and use if they are in compliance with all copyright and / or intellectual property. A copy of all or part, by any means, texts and images available in th is document is expressly prohibited unless the user respects the rights of autho rship and / or intellectual property, citing it properly to the document, includ ing imperterivelmente a clear reference to the author's website: "rftg.developme nt.googlepages.com. The material contained herein is only a general information based on personal experiences and is not intended in any way influence the reade r on any specific matter. The contents of this document are provided as a conven ience to readers and consist solely of non-binding information. The contents of this document are provided "as is" and does not offer any guarantee on it. The r eport's author disclaims any liability for losses that may occur because someone is based on information contained herein, since this information is for informa tional purposes only, not promised or guaranteed to be accurate, complete and up dated. The same applies to the contents of any reference made to it. Any dispute s arising out of or relating to use this document, or relating to copyright and / or intellectual property rights in materials that are part of this document sh all be governed by Portuguese law and subject to the jurisdiction of the courts of Portugal. Reading this document and its use implies the acceptance of these c onditions. © 2008 Ricardo Filipe Teixeira Gomes. rftg.development.googlepages.com CONTROL CHAMBER OF VIDEO SURVEILLANCE Ricardo Filipe Teixeira Gomes Electrical Engineering Department Instituto Superior de Engenharia do Porto 2008 This report satisfies all of the requirements contained in Instances of Mechatro nics Laboratory, 2nd year of Masters in Electrical Engineering and Computer Applicant: Ricardo Filipe Teixeira Gomes scientific Orientation: Lino Manuel Bap tista Figueiredo Company: Supervision: Lino Manuel Baptista Figueiredo Department of Electrical Engineering Instituto Superior de Engenharia do Porto May 5, 2008 Summary This work aims to develop a Dynamic Link Library (DLL) and an Application Progra mming Interface (API) capable of providing high-level methods that enable the co mmand / diagnosis of a video surveillance camera SONYTM IPELA SNC-RZ25. Addition ally, it also aims to develop a demo application potential of DLL and API. This same application also provides a starting point for an application desenvolviemn to video conferencing and multi-multiintervenientes spaces, totally independent of equipment manufacturer. It also proposed a system architecture of a distribut ed video conference, and made some considerations about its implementation. Keyw ords video surveillance, IP cameras, SONYTM IPELA SNC-RZ25, video conferencing. i

Index ABSTRACT ................................................. ..................... ............................. .................................................. ..... I CONTENTS ................................................ ............. ..................................... .......................................... ........ ...... III CONTENTS OF FIGURES ........................................ ...... .................................................. ...................... ............. V INDEX OF TABLES ........... .................................... .............. .................................................. .............. . VII ACRONYMS ................................................ ................ .................................. ............................................. . IX 1. INTRODUCTION ................................................. ......... ......................................... ................................... 1 1.1. 1.2. 1.3. 1.4. 2. BACKGROUND .............................................. ... .................................................. .................... 1 OB JECTIVES ................................................ ...................... ............................ .................................... SCHEDULE 3 ... ................................................................................ .... .................................... 3 ORGANIZATION OF REPORT ............. ................................. .............................................. .... ......... 4 APPROACH TO THE PROBLEM ............................................... ........ .......................................... ........ 5 2.1. 2.2. 2.3. CONDITIONAN TS ................................................. ........................... ....................... .......................... MOTIVATION .................. .............................. 6 ............................................... ... ................................... 6 FRAMEWORK ............................ .................... .................................................. ........ .................. 7 3. ARCHITECTURE OF THE SYSTEM ............................................... ..... ............................................. ....... 9 3.1. 3.2. 3.3. The DLL . ............................................... ................................ .................. .......................................... 10 API - FULL_FOR_ SNC_RZ25 ............................................. ......................... ......................... ..... 17 THE APPLICATION CON2MEC ..................... ......................... .................................................. ... ........... 19 4. 5. FUTURE DEVELOPMENTS ................................................ ........... ...................................... CONCLUSIONS ............................. ................... 23 .................................................. ...... ............................. 27 DOCUMENTARY REFERENCES ................................................ ........ .......................................... ........... 29 iii Index of Figures Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 Figure 12 Figure 13 Architecture of the developed software .................... .................................................. .... 9 c lass System ............................................... .................... .............................. ................. 12 class Exclusive_camera_contr

ol ............................................... ............................. ...... 13 class DAYNIGHT ............................................... ....... ........................................... ............ 14 class PanTiltZoomFoc us ............................................... ............................. .................. 15 class Camera_control_mode ................................ ............... ......................................... Class Camera ......... ...................................... 15 ...................................... ............ ............... 16 class Other_operation .......................... ..................... .................................................. . 17 Ge neral view of the application with the panel of CON2MEC arrows assets .......... ............... 20 Panel sliders application CON2MEC ........................... ............... ....... 20 ToolStrip to add new camera ......................... .................. .................................. 21 Dialog box for data ent ry of new camera ....................................... . 21 Architecture of a distributed video conference ..................................... 24 v Index of Tables Table 1 Timing of the project ............................................. .... ........................................... 4 vii Acronyms API DLL IP HTTP WWW URL JPEG - Application Programming Interface - Dynamic Link Library - Internet Protocol - World Wide Web - Hypertext Transfer Protocol - Uni form Resource Locator - Joint Photographic Experts Group MJPEG - Motion JPEG MPEG Moving Picture Experts Group ix 1. INTRODUCTION With the increase in transmission capacities of current data networks, appear ev ery day new applications and new perspectives of development of products based o n the Internet. These developments prompted the interest in the business of vide o-surveillance, resulting in the appearance of cameras for video surveillance ov er Internet Protocol (IP). Currently, such devices due to its low cost, ease of interaction and high technology are used in various other types of applications including video conferencing. 1.1. BACKGROUND The majority of cameras for video surveillance over IP provide the captured imag e using a computer that runs an embedded web server. This way enable the monitor ing of the image through a simple browser. This is the simplest method of access to the images [1]. The most common format of the images displayed by this type of equipment is the Joint Photographic Experts Group (JPEG). In this case,€the t erm "streaming video" is certainly not the right one, given that only images are transmitted, or 1 frames in JPEG each time the server receives a request from the client (through a browser or application that implements the same mechanism) [1] [2]. Much of th e equipment already is providing transmission in Motion JPEG (MJPEG). In this ca se it is only necessary to send a command HyperText Transfer Protocol (HTTP) for

the camera provides a sequence of frames in JPEG format, at a predefined cadence, ie streams which in practice comprises a v ideo. Most technologically advanced devices already offer the acquired images in formats that enhance the high quality video, such with the Moving Picture Exper ts Group - 2 (MPEG-2) and MPEG-4 [2]. To the human eye, although cadences of fra mes to 16 frames per second (fps) to cause the sensation of descontinuiade image (typically "flash" image), cadences above 10 fps is sufficient to create a vide o can convey the feeling of movement. Currently, it is considered that a video a t 24 fps has cinematic quality. Usually the manufacturers of video cameras provi de surveillance over IP, along with the equipment, a whole range of software. Th e characteristics of this type of software varies between manufacturers, models and ranges of equipment. All equipment to allow monitoring of images collected, and if the equipment permits, the control / remote diagnostics as well as stream ing audio uni-directional or bi-directional, and even videos. Some software pack ages, most complete, have an integrated solution that allows management of acces s to one or more chambers (creating user accounts, assigning permissions, ...), simultaneous monitoring of images captured by several cameras, recording images collected in digital format, motion detection, motion tracking, video conferenci ng, and various other features. Although several devices allow the control / dignóstico through the web server i ntegrated in the equipment, using HTTP GET and POST commands, the communication protocols between applications / control and diagnostic equipment are mostly pro prietary and closed (for security reasons and / or commercial). 2 However, SONYTM has developed a proprietary protocol opened with the aim of stan dardizing the command / diagnosis of video equipment. This is called VISCATM (Vi deo System Control Architecture). But requires the use of an RS-232 to establish connections between devices [3]. 1.2. OBJECTIVES Based on a video camera surveillance SONYTM IPELA SNC-RZ25, the main goals of th is project are: • Development of a Dynamic Link Library (DLL) and an Application Program Interface (API) in C # language, so to enable monitoring / diagnostic e quipment using methods of high-level, • Provide all documentation to support int eraction with DLL and API developed directly in the DLL and API; • Ensuring the robustness and reliability of the DDL and API developed through implementation o f techniques for handling errors and exceptions; • Development of an application capable of integrating simultaneously monitoring several IP cameras as well as the control / diagnostic camera video surveillance used during project • Demonst rate and validate the potential of DDL and API developed through the application of its use in monitoring, control and diagnosis; • Ensuring scalability, modula rity and flexibility of DDL, API and application developed in order to enhance f uture developments; • Optimize application performance with use of multi-threadi ng. 1.3. SCHEDULE In order to meet the objectives proposed, was designed to temporal distribution of the various tasks throughout the period of time available for the project. Ta ble 1 presents this timetable.

3 Table 1 Timing of the project Activity \ week teaching project report preliminary report functional prototype delivery of the final report of the Drafting presentation preparation arguência Study protocol VISCATM Test command basic Pan-Tilt-Zoom Studies / interpretation of "CGI command manual" Development of the Library "Full_for_SNC-RZ25" and hold er Application Development "CON2MEC" Testing and Error Correction Test Final Pre paration of the final report of November 4 th 5th 6th 7th 8th December 9 th 10 t h 11 th Christmas Break January 12 th 13 th 1.4. ORGANIZATION OF THE REPORT In Chapter 1 we provide a brief presentation and contextualization of this work, outlined the main objectives related to its achievement and presented the sched ule for the completion of their basic tasks. In the following chapter 2, there i s a brief overview of the problem and said some condionantes, motivation and the ir framework of the project. Throughout the 3rd chapter describes the system arc hitecture, explaining the DLL, API and application development. Following is the 4th chapter, where future developments are put in perspective, being a brief fi nal note, the listed priorities. The 5th and final chapter presents some of the conclusions result from this project. 4 2. APPROACH TO THE PROBLEM The generality of equipment for video surveillance over IP software are able to provide monitoring image, and control / diagnostic equipment. This can run on th e client machine or the equipment itself and is accessible through a web browser or a dedicated application. Notwithstanding the advantages of an application de veloped by professionals dedicated to a particular manufacturer, factors such as lack of flexibility / modulariade and closed source applications, limit its use and determine possible solutions for integration with equipment from different vendors and technologies. Solutions capable of such integration are not at all c ommon. For the equipment used in the project (video surveillance camera SONYTM I PELA SNC-RZ25), it is noted that it has an integrated server that implements sev eral commands HTTP GET and POST, in a way that could be considered as a method o f high- level. But they remain in their syntax and semantic characteristics of l ow-level actions, nor can the abstraction it desirable for the medium. 5 2.1. RESTRICTIONS Equipment manufacturers already provide such applications and software packages extremely complete, which allow the monitoring / diagnosis and monitoring. In pa rticular, the equipment will be used for project development, has a very compreh ensive software package with all the features already listed. Clearly not make s ense to develop a similar application. Typically each manufacturer has a set of command / communication protocols distinct, so that in the context of this proje ct was not feasible a generalist approach at the level of control / diagnostic e quipment than that available for its completion. The use of IP takes advantage o f the perspective control / remote diagnostics (from virtually any location with access to the World Wide Web (WWW)) and eliminates the need for two separate ca bles for the same equipment (command + image transmission). But has some weaknes ses in terms of security and any requirements of real-time. In contrast, connect

ing via RS232 can ensure real-time control and overcome weaknesses in security. However, despite being still possible to monitor images from any location, the d istance between the equipment and the control station / remote diagnosis is redu ced to an extremely distance limited (limitations of standard RS-232). 2.2. MOTIVATION Analyzing the information gained, and the constraints laid down, there is a pote ntial problem that needs to be resolved. The development of an implementation mo nitoring cameras for video surveillance over IP takes on a character in itself i rrelevant, since there are already several applications available on the WWW tha t satisfy this requirement in a manner quite satisfactory. But an application ca pable of concentrating the monitoring of several cameras for video surveillance over IP, such as providing command / diagnosis camera available for this project , may raise interest. 6 Known the purpose of the future, integrating the equipment in question in a vide o conferencing application, the perspective of developing an API DLL and a robus t, modular and flexible assumes an important character, not least because, when studying the state of the art performed there were no similar solution. The pote ntial inherent in the object-oriented programming, especially when it uses the C # language, as well as the growing numbers of developers this kind of language and ease of learning of it, motivates the development of all code is done in thi s language. 2.3. FRAMEWORK The solution described in this work is intended to fall within the desenvolvimem to an application of video conferencing,€allowing for the exchange of images bet ween multiple physical spaces and multiple users simultaneously. The developed a pplication already meets some of these requirements, particularly as regards mon itoring and management of cameras displayed. The independence of the DLL and API towards the application, ensure that changes to any of these components do not bind the solution encontarda, enhancing future developments. 7 3. ARCHITECTURE OF THE SYSTEM The project conducted possessed was limited only to desenvolviemnto software. Th e architecture of the developed system is based on three fundamental components, representable by the layering scheme of Figure 1: Application API DLL: Camera ... ... ... PanTiltZoomFocus Figure 1 Architecture of the developed software 9 3.1. The DLL The HTTP GET and POST commands, provided by the server in this equipment alone a

re already likely to be considered as methods for interacting with a subject (th e camera), providing a high level of abstraction in relation to the actions of l ow inherent internal functioning equipment. However, there is no type of error h andling and / or exceptions on the client side as well as some semantic level of controls remains a logic low level (eg, the positions of Pan are in hexadecimal format and not shaped angular degrees). Additionally, any return Inquiries resu lting from the device is received in the form of a string, consisting of the con catenation of several parameters simultaneously. The DLL developed aims, through the introduction of a new software layer to abstract the programmer from these details. Thus, access to the device is performed at a higher level, using method s consistent format, semantics clear / direct and simplified syntax. The fact of error handling / exceptions be provided at the DLL provides, in a fully transpa rent, effective containment of the spread of errors / exceptions directly on the lower layer, avoiding the propagation to the application layer. The BDS is composed of several classes of objects, and each of those classes has a specific set of methods. The structure implemented aims to recreate the comma nd structure presented in [4]. Each class of objects is not more than a bunch of commands (System Exclusive camera control, Date and time, ...), and that each o f its methods, like public, correspond to each of these commands (WelcomeText "< Text>" AbsoluteZoom "<zoom position>", ...). With this it is intended, and also decrease the learning time and interpretation necessary, arrange in a simple way the various commands. The interaction with the device is bidirectional, ie, whe re there is, there is a method to allocate a certain characteristic of the equip ment (eg private string AbsolutePan (pan_angle short, short speed)) and a method complement that lets you know the status of a particular characteristic. The lat ter 10 always begin with "get_" (for example: pan_angle, short speed)). private string get_AbsolutePan (short Although not implemented all the methods of each class of objects corresponding to each of the commands of the various groups of commands, all are defined and s tructured. This will make sure that future developments meet the basic requireme nts of integration without changing the structure set. Pay attention to the foll owing descriptions. 3.1.1. ASPECTS COMMON TO ALL CLASSES All classes of objects have a set of identical methods and variables are fundame ntal to the implementation of definite structure, these being the following: • internal string set_LoginCredentials (New_Username string, string new_password) - A method that allows the definition of access credentials equipment with which you want to interact, the level of access defined - interna l - this method is visible only up to grade level where he was pronounced; • • set_URL internal string (string new_URL)

- A method that allows the definition of Uniform Resource Locator (URL) of the equipment with which you want to interact; Private Request (string action) - Method used to perform the WebRequest formulated, the level of defined access - private - so this method is visible on ly within the class where it is created, it is noted that only receives as input parameter "string • • • • • action "; private string URL - Variable that allows the URL, can only be set by set_URL method; private string command_URL - Variable that allows the static component of the command to formulate common to the respective group of controls; private string action - Variable that allows the dynamic component of the command formulate; private string username - Variable that allows the value of the username, can only be defined by using the method set_LoginCredentials; private string password - Variable that allows the value of the password, can only be defined by using the method set_LoginCredentials; 11 As presupposes the object-oriented programming, variables and methods of no inte rest to the upper layers are protected by restricting its domain to its scope. 3 .1.2. CLASS "SYSTEM" This class aims to implement controls inherent in the interaction with the equip ment at identifying properties / characteristics of the system (model, serial nu mber, control of axes available, ...), as well as basic states in terms of its l ayer presentation (text "welcome", a definition of how to allocate URL, ...). Fi gure 2 summarizes all the available methods in the class "System". Note that the methods that they are to be made available to the higher layers of software com e with a defined level of public access-type. We can also identify the presence of a particular method inq_system () private string - Whose aim is the realization of the inquiry request, and receiving response which followed a string with all the strands of the Inquiry Parameter "system" a ssociated with system.cgi [4]. This method will always be called by any of the m ethods "get_ ..." when its use.

Figure 2 class System 12 Figure 3 Exclusive_camera_control class 3.1.3. CLASS "EXCLUSIVE_CAMERA_CONTROL" In this class, besides the methods common to all classes, there are three contro l methods (and their complementary Inquiries related) which affect the control o f the equipment. In a similar way to the class "System", there is a specific fun ction for the inquiry posed by this group of methods. 3.1.4. CLASS "DAYNIGHT" For the class "DAYNIGHT" it is noted that only two methods were implemented most important of this group: • • public string DayNightMode (string order) - To define how as equipment does the night vision mode; public string DayNightOnOff (string order) - Allows on / off mode of vision night. Additionally yet implemented their complementary (and get_DayNightMode get_DayNightOnOff) and also the method associated with the process of inquiry (inq_camera). 13 Figure 4 class DAYNIGHT 3.1.5. CLASS "PANTILTZOOMFOCUS" It is in the class "PanTiltZoomFocus" which are established methods for the cont rol of mechanical functions of the camera, as well as those that allow to obtain the physical coordinates of the view plane. In order to make your utlização mor e intuitive and simple, this class has some differences with regard to the simil arity of their methods for commands presented in [4], so it is advised to consid er only the presentation available in this work. It is noteworthy that some of t he methods listed in this class need to resort to methods of class "Camera" in o rder to fulfill their duties. Thus the constructor of the class "PanTiltZoomFocu s" appears overwhelmed by an object "cam" type class "Camera" public PanTiltZoomFocus (Camera cam). Thus it is allowed within the class "PanTiltZoomFocus" there is an object of type "Camera" (the "path"), so the methods from the "Camera" can be used [5]. 14

Figure 5 class PanTiltZoomFocus 3.1.6. CLASS "CAMERA_CONTROL_MODE" This class provides the methods needed to define parameters related to the metho d of physical control of the chamber. Figure 6 Camera_control_mode class 15 3.1.7. CLASS "CAMERA" The class "Camera" was undoubtedly the largest of the development. Some of the m ost important and most relevant properties of the equipment, which can be contro lled, contained in this class. Figure 7 Camera class 16 3.1.8. CLASS "OTHER_OPERATION" For this class, was implemented only one method (besides those taken with key). This allows to start or restart the machine. Figure 8 class Other_operation 3.1.9. CLASS NOT IMPLEMENTED All classes that are not listed above have not been developed. But its structure and methods / core variables were implemented. 3.2. The API - FULL_FOR_SNC_RZ25 As mentioned in the previous chapter, the DLL provides methods developed that ab stract the programmer from all aspects of the formulation and implementation of HTTP GET and POST commands, error handling and exceptions,€Inquiries return form atted commands and transduction of low-level semantics. However, the intention t o integrate all the objects of the DLL, and need for some methods rely on the me thods of other objects, led to an API that was developed. With use of this API, the programmer, after adding namespace Full_for_SNC_RZ25 you just need to create an object of type NetCam_SNC_RZ25 (or an array of this kind) to access various groups of methods, that these groups ar e in fact objects in the domain of the API. 17 For example, if you want to change the contrast of the image available, change t

he absolute orientation of the camera and know the current image CODEC in use, s imply the following code: using Full_for_SNC_RZ25; ... (... / / Object creation NetCam_SNC_RZ25 NetCam_SNC _RZ25 CAM1 = new () / / put cam1.Camera.Contrast contrast = 5 (5) / / Pan = 30; Tilt = 60 º; travel speed = 10 cam1.PanTlitZoomFocus.AbsolutePanTilt (20 , 60, 1 0) / / puts the value of the CODEC from "CODEC_em_uso string CODEC_em_uso cam1.C amera.get_ImageCodec = (); ... ) ... Between other possibilities, the that API may without any type of objection / difficulty of integrating directly or indirectly sets new methods th at makes available another type of action, using the existing methods. For examp le, notice the following snippet of code: ... / / New instance method that "sweeps" the entire area visible public void va rrer_ambiente () (int tilt; for (tilt = -30; tilt == 90; tilt + = 10) (PanTlitZo omFocus.AbsolutePanTilt (170, tilt, 20) ; While (PanTlitZoomFocus.getTilt ()! = tilt); While (PanTlitZoomFocus.getPan ()! = 170); PanTlitZoomFocus.AbsolutePanTi lt (-170, tilt, 20); While (PanTlitZoomFocus.getPan ()! = -170); / / if zoom ran ge, lower pitch tilt, change speed, change path, schedule, motion, etc ... )) 18 3.3. APPLICATION CON2MEC The developed application - CON2MEC - presents itself as an end solution capable of providing monitoring functions of several cameras for video surveillance ove r IP, as well as to monitor / diagnose for a camera SONYTM IPELA SNC-RZ25. Assum ing that the application would have only one thread, considering that from the m oment it is realized in a given WebRequest in order to acquire a frame until it receives the entire frame, the application does not perform any other action. Th e solution to this problem is found to be used for multi-threading techniques. T hus multiple tasks can be performed "simultaneously" within the same parent appl ication. In order to proceed with the implementation of techniques multhi-thread ing, more efficient and robust, it was decided to create a vector of type Thread eight positions, each of these corresponds to each

PictureBox hosting the displayed image. Whenever a camera is added a new thread is launched, and the method associated with it, camBox_handler (object position), private void triggers the necessary actions to update image of their PictureBox at a rate of 10Hz. This occurs until it is off to the chamber panel of the application when it is called the method close_connection (short cam_number) to end the thread corresponding to Board index cam_number vector threads. As can be seen in Figure 9, the application CON2MEC provides a series of command s to interact with the camera used in the project. In particular note that the c ommand is visible through a panel PanTiltZoom arrows. Alternatively you can sele ct the command PanTiltZoom through sliders (selecting "slidebar control") presen ted in Figure 10, which supersedes the position occupied by the panel of arrows. The addiction of new cameras is easily accomplished by using the menu "Configur ation" -> "Add Camera" -> "Add new camera", as shown in Figure 11, which activat es the dialog shown in Figure 12. 19 Figure 9 General view of the application CON2MEC with the panel of active arrows Figure 10 Panel sliders application CON2MEC 20 Figure 11 ToolStrip addition of new camera Figure 12 Dialog for data entry of new camera 21st 4. FUTURE DEVELOPMENTS A possible future development of this project may be based on building an infras tructure for video conferencing flexible, scalable, distributed and capable of s upporting a large number of actors / spectators. Figure 13 shows an enlarged dia gram of a possible structure. The figure does not mention any details concerning logical connections established between each of the agents,€so the following de scription is crucial. Due to the camera video surveillance to provide a manageme nt service access control, configuration and monitoring through an integrated se rver, it will be entrusted with the security of access to such equipment. Howeve r necessary to ensure that both the data network (LAN) or the amount of media se rver (SERVER), the security of such information will not be called into question . 23 @ My_domain1 Board controlled locally via RS232 or via ETHERNET Total transparen cy in networks SWITCHED ETHERNET cameras controlled remotely via Ethernet @ My_d omain1 LOCAL CAM SWITCH

RS232 @ My_domain2 ETHERNET SWITCH ` LOCAL CLIENT LOCATION ADMIN LOCAL CLIENT @ My_domain3 LOCAL CLIENT SERVER Remote Client Remaining Services + INTERNET REMOTE CLIENT REMOTE CLIENT Total openness to Wireless `REMOTE REMOTE CLIENT ADMIN Possibility of remote administration Camera controlled remotely via the Internet Figure 13 Architecture of a distributed system of video conferencing 24 Each device only has the ability to manage the direct access to an administrator and 9 users (using authentication USERNAME + PASSWORD). It is also possible to allow / prevent access by policies limiting the level of IP. In each chamber sho uld be configured an administrator with full privileges, by assigning a pair USE RNAME + PASSWORD. The server, which will have just as role disponibizar multimed ia content for Internet or LAN, should be designed exclusively with privilege of read access to multimedia content of each chamber. Thus links are established p eer-to-point secure, which can be authenticated by a set USERNAME + PASSWORD, an d under total control of the Trustee. The safety of access to multimedia content available from the SERVER should be controlled by the same or another qualified entity (eg.: FIREWALL). All media content via Ethernet or circulate only in a m ore abstract way, via the Internet. However, data related to the control / confi guration of the devices may move via Ethernet or through point to point links (A DMIN LOCAL CHAMBER) via RS232 protocol using the VISCATM. Taking into account these peculiarities, as a matter of system architecture, all local client (local client), sputum is strictly necessary, they are accessing c ontent through the server, as if they were remote clients (REMOTE CLIENT). Thus the local scale is never compromised by limitations related to the characteristi cs of the camera. Easily be inferred that the proposed architecture ensures full scalability in terms of direction and spatial distribution of the stakeholders,

ie, implements the concept of video conferencing and multi-space multi-user, as opposed to the classic model of "duo-conference." Additionally, it is still val id to say that the dynamics of access will only be dependent on the capabilities of (s) SERVER (s), or the level of access management, both in the provision of services (internal / external). Thus is raised the security level and broken lim iting the number of players in the video conference. Note however that in order to achieve this objective, it crucial that initially was developed the code nece ssary to the acquisition and transmission / reception 25 audio via IP. Improvements to the level of image format presented should be achi eved by presenting the MJPEG format as the most flexible in this project. 26 5. CONCLUSIONS The completion of this project premit conclusion, clearly, that on IP video surv eillance cameras have several potential level of development of applications in the areas of video surveillance, but also video-conference. It was also possible to conclude that the interaction of the programmer with a web server, owned adv antageous features, especially when the objective is the development of small ap plications, or other HTTP-based. But this same factor determines the development of applications for medium or large scale. Due to the nature of the application CON2MEC was possible to prove that the implementation of DLLs and APIs dedicate d, despite consuming substantial development times, present themselves as the mo st effective solution to such problems. Despite the difficulties encountered dur ing the development of the project at all times were clear advantages inherent i n using a programming language oriented to objects, such as C #. 27 Documentary references [1] Brick House Security - All About IP Network Video Cameras, Brick House Secur ity, New York, 2007, http://www.brickhousesecurity.com/about-ip-network-videocam eras.html. Kirilov, Andrew - Camera Vision - video surveillance on C #, The Code Project, Latvia, 2006, http://www.codeproject.com/KB/AUDIO-VIDEO/CAMERAVIEWER.A SPX. SONY - EVI-D30/D31 Command List (Ver. 1.21), SONY, 1999. SONY - SNC-RZ25N / P CGI command manual version 1.1, SONY Corporation, 2006. ARCHER, Thomas - Insi de C #, McGraw-Hill, 2002, ISBN 972-773-155-4. [2] [3] [4] [5] 29