Physical Safety for Schools Application Deployment Guide
Available Languages
Table Of Contents
Cisco Video Surveillance Media Server
Cisco Video Surveillance Operations Manager
Cisco Video Surveillance IP Cameras
Cisco Unified Communications Manager
Cisco Unified Communication Manager Express
Video Surveillance Media Server
Video Surveillance Operations Manager
Augusta EdgeFrontier Notifications to VSOM
Cisco 2500 and 4000 Series Cameras
Augusta EdgeFrontier Notifications to Singlewire InformaCast
Implementing and Configuring the Solution
Establishing Connection Between CPAM and Physical Access Gateway
Configuring Door Hardware and Access Policies
Configure CPAM to Send Requests to Augusta EdgeFrontier
Managing Permissions and Rights
Viewing Archived and Live video from the District Office
Setting Up Video Surveillance Operations Manager for Motion Detection
Setting Up the 2500 Camera for Motion Detection
Setting Up the 4000 Series Camera for Motion Detection
Cisco Unified Communications Manager
Cisco Unified Communications Manager Express
Augusta EdgeFrontier and Singlewire InformaCast
Appendix A—Reference Documents
Cisco Validated Design (CVD)Building Architectures to Solve Business ProblemsPhysical Safety for Schools ApplicationDeployment GuideLast Updated: October 27, 2009Cisco Validated DesignAbout the Authors
John Carney, Senior Manager, CMO ESE, Cisco SystemsJohn is a senior manager responsible for leading the definition of safety and security architectures on the Industry Solutions Engineering team. He joined Cisco in January of 2007 and has served as the Industry Solution Architect responsible for the Healthcare, Financial Services, and Public Sector verticals.
With over 25 years experience working in a service provider/data center environment, John's strength lies in his unique ability to understand the business issues facing our customers and how they relate to the components in a large computing environment.
During his career, John has obtained various industry certifications, including Novell's Certified Network Engineer, Microsoft's Certified Systems Engineer and various levels of Citrix certifications.
Jenny Cai, Vertical Solutions Architect, CMO ESE, Cisco SystemsJenny currently works with the Industry Solutions Engineering team and is responsible for developing and validating education solutions. Since joining the team, she also worked on validating solutions for the Financial Services vertical. Prior to this group, Jenny worked on the Cisco 7600 series router.
Prior to Cisco, Jenny worked on a fault-tolerant server for the Financial Services industry while at Stratus Computer, and a continuous-feed printer for the oil industry while at Atlantek.
Tony Anderson, Vertical Solutions Architect, CMO ESE, Cisco SystemsTony Anderson, CCIE 4686, is currently a Technical Marketing Engineer focused on Healthcare. In his 11 years at Cisco, Tony has also supported GE as a reseller and worked with Healthcare Application Providers to incorporate Cisco technologies into their solutions. In another role he was responsible for the development of Unified Communications training for partners. His 38 years in the Computer and Networking industries in positions ranging from Systems Engineer to Technical Instructor to Sales Manager gives him a thorough understanding of technology and how to apply those technologies to solve business problems. Tony has CCIEs in Routing & Switching and WAN Switching.
Fernando Macias, Vertical Solutions Architect, CMO ESE, Cisco SystemsFernando is a member of the Industry Solutions group at Cisco. As a Technical Marketing Engineer within the Enterprise Solutions Engineering (ESE), he is responsible for developing networking solutions that impact the Manufacturing industry.
With ten years of experience at Cisco, Fernando has developed networking solutions for Cisco's Physical Security business unit and was a member of Advanced Services, where he provided network design support to large customers, including Fortune 50 companies. Fernando also was a Systems Engineer for Cisco's commercial region.
With over 20 years of networking experience, Fernando has also worked for international manufacturing and construction engineering companies. In addition to Masters degrees in Technology Management and Software Engineering, Fernando holds a CCIE#11777 certification in Routing and Switching.
Contents
Contents
Physical Safety for Schools
Overview
Executive Summary
Education stakeholders need to focus on the safety and security of schools, colleges, and universities. With the wide spectrum of safety incidents occurring on campuses, the need to protect students and monitor school assets has become increasingly important. From natural to man-made incidents, across both the virtual and physical domains, education institutions today must confront myriad challenges, including the following:
•
Student, faculty, and staff safety
•
•
•
–
Using the Cisco end-to-end network as the platform, a variety of solutions can be deployed to meet safety and security needs. The Cisco Physical Safety for Schools solution portfolio features the following:
•
•
•
•
The Physical Safety for Schools solution provides educational institutions with the capabilities to evolve their schools into safe, secure institutions able to protect their students and respond appropriately in case of emergencies.
Solution Description
The Physical Safety for Schools solution focus on protecting the actual campus environments of schools and districts. Working with area law enforcement, facilities, and Information Technology (IT), schools can protect student data, better control network access, and help prevent unwanted intrusion.
The solution takes a holistic approach to security by integrating physical security devices with the IT infrastructures of districts and schools. See Figure 1.
There are three major functions of the solution as defined: detect, monitor, and respond.
Figure 1 Unified Command and Control
Detection takes on many forms, from keeping out unwanted guests at various times of the day to keeping in high value assets and equipment. The solution combines physical access control with video surveillance to provide a solid mechanism to secure educational environments.
Monitoring requires not only a way to watch what is happening, but a way to notify officials, faculty, and staff in the case of an emergency. Being able to correlate all of the alarms from the various sensors, cameras, and physical access control devices requires the ability to correlate that information and provide automated responses to avoid the need for human interaction in every situation. This correlation also provides a way to go back and review incidents, and creating plans and procedures to avoid them in the future.
Effective response requires a way to notify not only to the authorities, but also students, faculty, and parents. By integrating the correlation engine and the notification engine, notification to various groups of individuals can be automated. Additionally, there is the capability to provide proactive alerts and notification (i.e., egress directions, in the case of emergencies).
Solution Benefits
The Physical Safety for Schools solution provides several benefits to educational institutions, including the following:
•
•
•
•
Scope of the Solution
The Physical Safety for Schools solution focuses on the products and services necessary to create a safe environment for education. The scope of the solution focuses on the functional interaction between the products included. This also includes the actions/reactions necessary to properly secure the campus. Specific use cases have been tested in order to show the capabilities of the products, components and systems included.
This application deployment guide is not intended to instruct the reader on how to install and configure the specific components used in this solution. See the appropriate product user guides for installation and general configuration information for the appropriate products. References to these guide are provided in "Appendix A—Reference Documents" section.
Scale testing or load testing are not included in this application deployment guide. Where available, information has been included that covers some of these aspects.
High availability (HA) is always a challenging area to cover, with availability ranging from basic to 99.99999% uptime. This solution does not repeat HA testing that is covered at various component levels. Refer to the corresponding design guides listed in the "Appendix A—Reference Documents" section for HA at various component levels. The solution includes limited-scope HA testing. The design guide discusses how HA could be implemented for K-12 schools and universities.
For more information on the baseline architecture, see the Service Ready Architecture Design Guide at the following URL: http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns826/landing_srArchit_edu.html
For more information on designing and implementing video surveillance in an enterprise environment, refer to the Cisco IP Video Surveillance Design Guide at the following URL: http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns819/landing_vid_surveillance.html
Use Cases
This application deployment guide focused on uses cases that can provide added safety and security to educational institutions.
Smoke Alarm
If smoke is detected, there are multiple responses that need to occur in rapid succession, if not simultaneously. In some cases, an alarm from a single smoke detector does not indicate the presence of a fire. For example, it could just be a student lighting a cigarette in the lavatory or it could be a motor overheating in the mechanical room.
In the case of smoke, the camera in closest proximity should ensure that it has a video record of the incident, and notification should be sent to the appropriate staff to investigate the situation.
Multiple secondary alerts may be required (i.e., to the school administrator, to the teaching staff in close proximity to the alert, and potentially to the maintenance staff). These alerts should include which camera is within proximity so that any staff can access the camera feed directly to monitor the situation.
Fire Detection
This situation could be triggered in multiple ways, and could have different reactions based on the method of trigger; for example, a fire pull station or a fire detection sensor.
Multiple alerts need to occur in rapid succession or simultaneously. The camera in closest proximity should ensure that it has a video record of the incident, and notification should be sent to the appropriate staff to investigate the situation. Evacuation instructions should be announced over the public address system with the preferred evacuation path. All of the phones in the building should indicate the preferred evacuation path based on the location of the fire. The system could also place the 911 call and provide the fire location within the building.
Note
Hall Monitor
The potential for false positives is high in this situation. For example, it would not make sense to monitor a hallway for movement during the time between classes, and maybe not while the janitorial staff is working. But, after hours, when the hallways should be empty, any motion detected should trigger a notification so that a proper course of action can be determined. If a teacher decided to stay after hours to work on the next day's plan, that would not require a response. But, if a student was seen in the hallway after a predetermined time, this could indicate a situation that required a response. While it may not be possible to determine if the movement is the result of a student, a teacher, or even a mouse, the ability to quickly review and respond to the situation is required.
If motion is detected during defined hours, there should be no alarm notification. However, the video feeds should continue to be available for monitoring purposes.
If motion is detected outside of acceptable hours, the camera detecting motion should ensure that it has a video record of the incident, and notification should be sent to the appropriate staff to investigate the situation.
Additionally, if an abnormal incident occurs during normal working hours, a message could be sent to the staff on-site via the wireless phone and a prerecorded message could be sent to specific outside numbers (i.e., school administrators) indicating the nature of the alarm.
Forced Entry
The ability to monitor entry/exit doors is critical in the security of the building. The ability to identify when a fire door is opened that should not be, or an entry door opened after hours is a minimum requirement. By the same token, the exit doors can be opened during the day and should not create a notification situation. So similar to the motion detection, there is a need to monitor the doors and allow for different actions to be taken based on specific conditions (i.e., time of day).
If a fire door is opened during the day, the camera in the closest proximity should ensure that it has a video record of the incident, and notification should be sent to the appropriate staff to investigate the situation. The notification should provide the camera that is monitoring the door so that anyone can access the camera directly.
If an exit door is opened during the day, no alarm should be sent. If any door is opened outside of a predetermined time of day, notification should be sent to the appropriate staff to investigate the situation. The message should be sent to a predetermined list of individuals and the text should indicate the nature of the alarm. Depending on the workflow, a call should be placed to the police department and the video captured during the alarm situation should be forwarded to them for review.
In the case of a specific incident, an additional reaction to a situation could be the lockdown of a specific area that allows passage only to authorized persons; for example, an access to a mechanical room when smoke is detected. Allowing anyone access to that location could be dangerous and access should be controlled.
One other potential is controlling access during specific times of the day. For example, one school has been able to reduce tardiness in the students because they lock the entrance doors at a specific time of the morning. If students do not arrive by the specified time, they have to be allowed entry to the school. Knowing that they have the potential to be locked out of the school in the morning makes them more conscientious as to when they arrive.
At any time of the day, a forced entry is a critical incident. If a door sensor indicates a door is open but there is no associated card reader access or request for exit (exit from inside the building), it is a forced entry incident. Multiple alerts need to occur in rapid succession or simultaneously. The camera in closest proximity should ensure that it has a video record of the incident, and notification should be sent to the appropriate staff to investigate and respond to the situation.
Theft Detection
With the cost of hardware, software, and physical assets needed in the schools going up, the cost of theft for any of these assets is having a greater impact.
There are multiple ways to track assets within the campus, and the deployment and complexity will depend on the size of the campus that is being monitored. Using Active RFID tags and a wireless infrastructure with location-based services to actively monitor the movement of assets on the campus is one such mechanism. Alternatively, using passive RFID tags on the physical assets and securing the perimeter to monitor any assets moving outside of the secured area is a less expensive alternative.
By using passive RFID tags on physical assets and locating RFID exciters at the exits, it is possible to effectively monitor the movement of the assets outside of the secured perimeter.
Should an asset pass through the exit door at any time of day or night, the camera in closest proximity should insure that it has a video record of the incident. Additionally, a text message should be sent to all phones associated with security notifying that an asset has been removed, the type of asset that was removed, the door that it passed through and the camera that is monitoring the situation. An audible alarm is optional.
CRE Integration
A more complicated example of physical security is the integration of the physical security system with the mechanical systems, or the Connected Real Estate infrastructure. An example of this would be the potential to shut down the ventilation system in the event of a fire in a particular location.
Take for example a fire detected in a particular location. Once that location is identified, a automated signal could be sent to the ventilation system to shut all dampers in the affected location, and to shut off electricity in that location. While this use case was not tested in the lab due to the lack of available hardware resources, it is easy to understand how this could work based on the integration done in other cases.
Solution Components
The solution includes Cisco security products such as physical access control and video surveillance in addition to networking and unified communication products. In addition, the integration with products from Augusta Systems and Singlewire software provides a complete end-to-end solution.
Cisco Physical Access Control
The Cisco Physical Access Control is a comprehensive solution that provides electronic access control using the IP network. The solution consists of hardware and software products and is modular, scalable, and easy to install. It allows any number of doors to be managed using the IP network. The Cisco Physical Access Control is also integrated with Cisco Video Surveillance Manager.
The Cisco Physical Access Control solution has two main components: Cisco Physical Access Gateway and Cisco Physical Access Manager. The Cisco Physical Access Gateway is installed near a door. The gateway has Ethernet ports to be connected to an IP network. This enables the gateway to be controlled over the network. To allow more inputs and outputs, additional Cisco modules (input, output, reader modules) can be connected to the gateway through a controller area network (CAN or CAN-bus). The door hardware connects to the gateway or other Cisco modules via either a Wiegand interface for card readers or directly to inputs for door sensors and output relays for locking hardware or Local Door Alarms. The gateway will function normally when network is down. Figure 2 shows a Physical Access Gateway.
Figure 2 Physical Access Gateway
The Cisco Physical Access Manager (CPAM) is a management appliance for configuration, monitoring, and report generation. CPAM server can support any combination of 2000 Access Control Gateways as well as input, output, or reader modules. Figure 3 shows a CPAM appliance and a management screen.
Figure 3 Cisco Physical Access Manager
Figure 4 shows a typical physical access control deployment with badge readers located at different locations. With the proper authorization, users are able to connect to the CPAM remotely through CPAM client software to manage the environment.
Figure 4 Physical Access Control Deployment
Cisco Video Surveillance
Video surveillance has been a key component of the safety and security groups for many organizations. As an application, video surveillance has demonstrated its value and benefits countless times by providing real-time monitoring of a facility's environment, people, and assets as well as by recording events for subsequent investigation, proof of compliance, and audit purposes.
For school systems that need to visually monitor or record events video, surveillance has become more important as the number of security risks increase. In addition to video analytics, the value of video surveillance has grown significantly with the introduction of motion, heat, and environmental sensors.
In a typical school environment, several systems are deployed for disparate applications, such as physical access control, fire and smoke detection, and video surveillance. These applications typically do not communicate with each other and require different management and support personnel. As a result, owners and operators suffer from a lack of operational consistency, interoperability, and capabilities that translate into higher capital and operational costs and limit the return on their system investments.
Cisco's solution offers software and hardware to support video transmission, monitoring, recording, and management. Cisco video surveillance solutions work in unison with the advanced features and functions of the IP network infrastructure—switches, routers, and other network security devices—to enable secure, policy-based access to live and recorded video.
Through the Cisco architecture, video can be accessed at any time from any place, enabling real-time incident response, investigation, and resolution. As an extension of the Cisco Self-Defending Network, the Cisco intelligent network enables educational institutions to use existing investments in video surveillance and physical access control while enhancing the protection of assets and the safety of students.
The open, standards-based Cisco infrastructure enables the deployment and control of new security applications and maximizes the value of live and recorded video, interacting with multiple third-party applications and video surveillance cameras.
The Cisco Video Surveillance solution relies on an IP network infrastructure to link all components. The design of a highly available hierarchical network has been proven and tested for many years and allow applications to converge on an intelligent and resilient infrastructure.
Figure 5 shows the main components of the Cisco Physical Security solution, including video surveillance, physical access control, incident response and integration with third-party systems.
Figure 5 Cisco Physical Security Components
Some of the benefits of Cisco's Video Surveillance solution include the following:
•
•
•
•
•
The main components of the Cisco Video Surveillance solution include the following:
•
•
•
•
•
•
The following subsections describe the components used for this solution.
Cisco Video Surveillance Media Server
The Cisco Video Surveillance Media Server (VSMS) is the core component in the Cisco Video Surveillance Manager solution and performs the following networked video surveillance system functions:
•
•
•
In Figure 6, the Media Server is responsible for receiving video streams from different IP cameras and encoders and replicating them as necessary to different viewers.
Figure 6 Video Surveillance Media Server (VSMS)
By using the power and advanced capabilities of today's IP networks, the Media Server software allows third-party applications, additional users, cameras, and storage to be added over time. This system flexibility and scalability supports the following:
•
•
•
•
Cisco Video Surveillance Operations Manager
Working in conjunction with the Cisco Video Surveillance Media Server, the Cisco Video Surveillance Operations Manager (VSOM) enables organizations to quickly and effectively configure, manage, and view video streams throughout the enterprise. Figure 7 shows the Operations Manager main screen, which is accessed through a web browser.
Figure 7 Video Surveillance Operations Manager
The Operations Manager meets the diverse needs of administrators, systems integrators, and operators by providing the following:
•
•
•
•
•
•
•
•
•
•
•
Cisco Video Surveillance IP Cameras
Cisco 2500 Series Video Surveillance IP Camera
The Cisco 2500 Series Video Surveillance IP camera is a high resolution standard-definition, feature-rich digital camera designed for secure performance in a wide variety of environments. The camera supports MPEG-4 and MJPEG compressions with up to 30 frames per second.
Contact closure and two-way audio allow integration with microphones, speakers, and access control systems. By providing wired and wireless models, the Cisco 2500 IP camera provides an ideal platform for integration and operation as an independent device or as part of the Cisco Video Surveillance network. Figure 8 shows both the wired and wireless models of the 2500 IP Camera.
Figure 8 Cisco 2500 Series IP Cameras
The 2500 Series IP camera provides the following features:
•
•
•
•
•
Cisco 4000 Series Video Surveillance IP Camera
The Cisco Video Surveillance 4000 Series IP Cameras employ true high-definition (HD) video and H.264 compression, streaming up to 30 frames per second at 1080p (1920 x 1080) resolution. The Cisco 4000 IP Camera series also supports contact closure and two-way audio allow integration with microphones, speakers, and access control systems.
The Cisco 4000 Series includes two models: the CIVS-IPC-4300 and CIVS-IPC-4500. These cameras have identical feature sets, with the exception of the additional digital signal processor capabilities specifically designed to support real-time video analytics at the edge on the CIVS-IPC-4500. On this model, applications and end users have the option to run multiple analytics packages without compromising video streaming performance on the camera.
Figure 9 shows a Cisco 4000 IP Camera with an optional DC Auto Iris Lens.
Figure 9 Cisco 4000 Series IP Camera
The 4000 Series IP camera provides the following features:
•
•
•
•
•
•
•
•
Cisco Unified Communications
Cisco Unified Communications offers a new way to communicate. This comprehensive, integrated IP communications system of voice, video, data, and mobility products and applications enables schools to use their network as an intelligent platform for effective, collaborative, scalable, and secure communications to better run the school system.
By integrating the systems with an intelligent IT infrastructure, the network is transformed into a "human network" that offers an organization the ability to access information on demand, to interact with virtual teams wherever they are, and to manage these interactions on the go, in real time.
In this solution, the Cisco Unified Communications system offers a method for providing audio and text notification of alerts and can provide information customized for the specific alert. For example, if a fire alarm is triggered in the school gym, an audio and text message could be transmitted to all the IP phones and other IP enabled communications devices (such as IP-based speakers) with the following message "A fire has been detected in the gym. Please exit the building through the main entrance". If an intruder is detected after hours, audio and text messages such as "an intruder has been detected in the north hall" could be sent to all phones associated with security.
The minimum configuration required for a Cisco Unified Communications system is a call control server (Cisco Unified Communications Manager, Cisco Unified Communications Manager Business Edition, Cisco Unified Call Manager Express, or Unified Communications 500), IP phones (hard phones and/or soft phones), and a gateway to communicate with the PSTN. Additional components that are typically deployed are a Presence Server to provide presence information (available, on the phone, in a meeting, etc.), either Unified Messaging or voice mail, and WebEx.
The following sections describe the components used in this solution.
Cisco Unified Communications Manager
The Cisco Unified Communications Manager Express (CCME) integrates a core set of key system and small PBX functionality with a wide variety of rich IOS voice features inside the Cisco multiservice and integrated services routers. By converging voice and data into a single platform, CCME streamlines operations and lowers network costs, while increasing productivity.
CCME is optionally available on the Cisco 1861, 2800, 3800 Series ISRs, or the IAD 2430 to customers with 240 or less users. Whether deployed through a service provider's managed services offering or implemented directly by the end customer, CCME provides an intuitive graphical user interface for easy moves, adds, and changes; internetworking with Cisco Unified Communications Manager; and a number of advanced features not available on traditional telephony solutions.
The Cisco Unified Communications Manager, deployable on the Cisco 7800 Series Media Convergence Servers or on third-party servers by HP or IBM, includes the following features:
•
•
•
•
•
•
Cisco Unified Communication Manager Express
The first of its kind, the Cisco Unified Communications Manager Express (CCME) integrates a core set of key system and small PBX functionality with a wide variety of rich IOS voice features inside the Cisco multiservice and integrated services routers. By converging voice and data into a single platform, CCME streamlines operations and lowers network costs, while increasing productivity.
CCME is optionally available to any customer with 240 users or less who owns or is looking to purchase Cisco 2800 and 3800 Integrated Services Routers or the IAD 2430 and Cisco 1861. Whether deployed through a Service Provider's Managed Services offering or implemented directly by the end customer, CCME provides an intuitive graphical user interface for easy moves, adds and changes; internetworking with Cisco Unified Communications Manager; and a number of advanced features not available on traditional telephony solutions.
CCME provides the following features:
•
•
•
•
•
•
•
•
•
Phones
Cisco provides a complete range of next-generation communications devices that take full advantage of the power of the data network while providing a convenient and easy-to-use system. The Cisco Unified IP phones can enhance productivity and address the needs of entire organizations.
Simple-to-use and fully featured, the Cisco Unified IP phones provide an enhanced user interface with display-based access to features, productivity-enhancing applications, and value-added services. This portfolio of robust next-generation devices includes the industry's first Gigabit Ethernet IP phone.
Cisco offers a comprehensive portfolio of IP phones. With their distinctive look, the phones provide a unique, positive communications experience. Their advanced unified communications services and applications are available only with an exclusively IP solution.
Easy-to-use display:
•
•
•
•
•
•
Modern style:
•
•
•
Ease in adding new features:
•
Increased accessibility:
•
•
•
•
•
•
Partner Products
Augusta EdgeFrontier
Augusta EdgeFrontier is a remotely configurable middleware that resides on a server or servers providing a complete platform for intelligent convergence solutions. Augusta EdgeFrontier is a drop-in software solution that supports the convergence of devices, systems, and networks where robust network infrastructure exists.
Augusta EdgeFrontier supports the integration and normalization of data, events, and control functions from diverse sources, regardless of manufacturer or communications protocol, including devices and systems utilized in safety and security, energy and utilities, asset tracking, and other applications. In addition, Augusta EdgeFrontier provides structures for event processing and configuration of event or policy-based actions through a policy engine. See Figure 10.
Figure 10 Augusta EdgeFrontier Converged Network
Augusta EdgeFrontier is made up of an EdgeFrontier engine application, which provides the field-level power for the software, and an EdgeFrontier client application, which enables customers to configure/support the EdgeFrontier engine application remotely.
Augusta EdgeFrontier can distribute data to and exercise control over multiple network devices and applications via various communication protocols within wired and wireless deployments including WiFi, WiFi mesh, WiMax, ZigBee, and others. In addition, third-party processing software and algorithms or user-produced code can be implemented easily to further extend the capabilities of Augusta EdgeFrontier as a middleware platform technology for convergence.
Specifically, Augusta EdgeFrontier can:
•
•
•
•
•
•
•
•
•
Singlewire InformaCast
Notification to Cisco Unified Communications phones and IP-based speakers was accomplished using Singlewire InformaCast IP broadcasting solution from Singlewire. Singlewire InformaCast is a server or Cisco AXP-based application that can be used to simultaneously send an audio stream and text messages to any combination of Cisco IP phones, Singlewire InformaCast-compliant IP speakers, and PCs. With the push of a single button on the phone or a single click from a PC, a user can send a live, recorded, or scheduled broadcast to one or more paging groups.
•
•
•
•
•
•
•
•
•
•
•
•
Typical uses:
•
•
•
•
•
Solution Framework
Figure 11 shows the location of the various components used in the Safety and Security for Education solution. The solution is based on the Service Ready Architecture (SRA) design and expands on the previously published Notifi-Ed solution. Figure 11 shows how each solution builds on top of the next, providing a complete solution architecture for safer educational environment.
Figure 11 Safety and Security for Education—Based on SRA
Designing the Solution
There are multiple considerations that need to be addressed when designing a solution as large and integrated as Safety and Security for Education (see Figure 12). The components allow for a great deal of flexibility and scale, so selecting the appropriate products for the proper location is crucial. The design presented here attempts to show the various components and alternatives available based on size and scope of the customer environment. The ability to mix-and-match components and deployment options should give enough variety to meet most deployment needs.
Figure 12 District Office, School 2 and School 3 Lab Environments
With this type of deployment, it is assumed that the district office contains the data center environment, and has the staff necessary to support the technology. Scope dictates the components used.
For the Cisco Communications Manager, it is assumed that a CUCM cluster resides in the data center environment and is used for all phones in the district. To provide phone service in the case of a WAN outage, each school location would have a 2800 or 3800 series ISR to provide voice gateway and Survivable Remote Site Telephony (SRST) functions.
A single Video Surveillance Operations Manager (VSOM) server would be used in the district office. This server would be used to manage the Video Surveillance Media Servers (VSMS) used at each school. By placing a VSMS server at each location, bandwidth requirements are minimized to support multiple remote cameras, but still provide a centralized management capability and the ability to view remote video feeds. These feeds would also be available by any device on the network (assuming proper credentials) so that video can be viewed locally as well.
Cisco Physical Access Manager (CPAM) is the server side management tool for Cisco Physical Access control. This is located at the district office to provide a centralized management tool that can be used to control all of the Physical Access Gateways in the district.
Augusta EdgeFrontier servers are placed at each site. This allows for a centralized correlation point at each site, which can be used to enhance network security and minimize bandwidth requirements on the WAN.
Singlewire InformaCast is placed in the district office to handle all of the notifications for the district. Centralizing the Singlewire InformaCast server when managing schedules, notifications and CUCM interaction is one of the benefits of the product. However, schools without a backup MAN connection need to install a local copy of the Singlewire InformaCast application. Refer to the "High Availability" section on page 33for details.
For the test environment used, the district office included the following components:
•
•
•
•
•
•
•
•
School 2 (and subsequent schools) included the following components:
•
•
•
•
•
There may come a time where deploying a full video surveillance solution with multiple servers, hundreds of camera and the supporting infrastructure is just not necessary. For the environment listed as School 4 shown Figure 13, the design focuses on delivering a fully-integrated solution at a standalone site.
Figure 13 School 4 Lab Environment
In this design, the choice of components used is the biggest difference. For example, instead of deploying multiple servers to support the VSOM and VSMS, the testing was performed with a VMSS module in a 3800 ISR and included the ISS module, which provides an additional 500Gb of storage. The software on the VMSS module is the same version/release as that used on the VSOM/VSMS, but in a smaller, easier to manage package. Same functions exist, the biggest difference being the number of cameras that are supported. There is an option for 16 or 32 cameras supported by the VMSS module. If more cameras are necessary, it will be necessary to deploy the server strategy in the district office/remote school scenario.
Another change in this design is the use of the Cisco Unified Communications 500 device. This device is based on CCME, and could be used in the design instead of CUCM. Additionally, a 3800 ISR with SRST functionality also provides the option of deploying Cisco Unified CME on the ISR while providing the same level of functionality.
In this design, the need for servers still exists, but the size and horsepower of those servers is not as great as in an enterprise deployment. For testing purposes, the Singlewire InformaCast server and Augusta Augusta EdgeFrontier servers were both installed on a VM guest machine running on a single Cisco MCS 7835 server. The memory and processing requirements are minimal, so this posed no problems from a performance perspective. Additionally, the Singlewire InformaCast server is available to be deployed on a Cisco AXP blade in the 3800 ISR, so if there is an open NME slot, this is a reasonable alternative.
The Cisco Physical Access Control was not tested in the isolated scenario, but the design and deployment considerations would be the same as for the district office and remote school environment.
For the test environment used, the standalone environment known as School 4 (see Figure 13 above) included the following components:
•
•
•
•
•
•
•
Cisco Physical Access Control
The Cisco Physical Access Control solution benefits from a distributed architecture while lowering deployment and operational costs. For this application deployment guide, the Cisco Physical Access Gateways are placed at each school. CPAM is centrally located at the district office and is able to manage thousands of gateways installed at the schools. Through CPAM, a user can configure the policy for each access gateway at each school. For example, the entrance door to the school will remain locked during school hours from 8:00am to 3:30pm, while a door to a building may be unlocked during class break.
CPAM and Augusta EdgeFrontier
For emergency situations, such as a forced entry, CPAM will send an HTTP request to the Augusta EdgeFrontier application. The Augusta EdgeFrontier application will trigger notification to security officers and instruct VSOM to archive videos before and after the incidents. This application deployment guide focuses on two types of incidents: forced entry and theft. Figure 14 shows the interaction between CPAM and Augusta EdgeFrontier.
Figure 14 Interaction between CPAM and EdgeFrontier
The Cisco Physical Access Gateway and CPAM exchange information through an encrypted protocol over MAN. While the traffic is light, a QoS policy is required to guarantee this important traffic during congestion.
Cisco Video Surveillance
Video Surveillance Media Server
The Video Surveillance Media Server is the core component of the solution, providing for the collection and routing of video from IP cameras to viewers or other Media Servers. The system is capable of running on a single physical server or distributed across multiple locations, scaling to handle thousands of cameras and users.
Figure 15 shows how IP cameras send a single video stream to the Media Server. The Media Server is responsible for distributing live and archived video streams to the viewers simultaneously over an IP network.
Figure 15 Media Server
For archive viewing, the Media Server receives video from the IP camera or encoder continuously (as configured per the archive settings) and only sends video streams to the viewer when requested.
In environments with remote branch locations, this becomes very efficient since the traffic only needs to traverse the network when requested by remote viewers. Branch office traffic remains localized and does not have to traverse wide-area connections unless is requested by users other users.
Video requests and video streams are delivered to the viewer using HTTP traffic (TCP port 80).
Video Surveillance Operations Manager
The Operations Manager is responsible for delivering a list of resource definitions, such as camera feeds, video archives and predefined views to the viewer. Once this information is provided to the viewer, the viewer communicates directly with the appropriate Media Server to request and receive video streams. Viewers access the Operations Manager via a Web browser.
Figure 16 shows the traffic flow of video requested by a viewer.
Figure 16 Operations Manager Traffic Flows
Once the user authenticates to the Operations Manager, the user is presented with a list of predefined views, available camera feeds and video archives, based on defined access restrictions. From this point forward, the user interacts directly with the Media Server to retrieve video feeds. The connection remains active until the OM Viewer selects a different video feed.
The Media Server acts as a proxy between the camera and the viewer, which receives video feeds over TCP port 80 (HTTP). If another OM Viewer requests the video from the same IP Camera, the Media Server simply replicates the video stream as requested, and no additional requests are made to the camera (each feed is sent via IP unicast to each viewer).
Augusta EdgeFrontier Notifications to VSOM
For the integration with VSOM, this deployment guide relied on the soft trigger mechanism of the VSOM server. This is simply a GET call to the VSOM server from the Augusta EdgeFrontier server with the properly-formatted URL that is defined when a trigger is created. The only difference between triggers is the ID number. The soft trigger needs to be created in VSOM before an Augusta server can initiate the request.
Once the trigger is called, additional functions are performed based upon the setup of the trigger itself. Use cases defined for this solution include the marking of the video from N seconds before the incident until Y seconds after the incident, and how long to keep the video. Additional configuration options include adding the incident to the event list in VSOM and provide a notification on the VSOM Operations view that an incident has occurred. SeeFigure 17.
Figure 17 Augusta EdgeFrontier Notifications
Required TCP/UDP Ports
The example in Figure 18 shows that the communication between the Media Server and viewers relies on TCP port 80 (HTTP) while the communication between edge devices and the Media Server may vary, depending on the camera manufacturer.
Figure 18 Required TCP/UDP Ports
In order to allow video streams to flow between the Media Server, edge devices and viewers, the proper security must be in place to allow TCP/UDP ports to traverse the different subnets or locations.
Time Synchronization
The Network Time Protocol (NTP) is widely used to synchronize clocks of viewers, application servers, routers and other network elements with a reliable time source. The Cisco Video Surveillance Manager solution relies on NTP to synchronize the time of all its applications and viewers. Clock synchronization is critical when retrieving previously recorded video streams. Figure 19 shows how the NTP servers propagate the current time to IP cameras, viewers and application servers.
Figure 19 Network Time Protocol (NTP)
The application servers and viewer's workstations should be configured to receive time from an NTP server.
Note
Distributed Media Servers
Figure 20 shows a deployment with several remote schools, each with a local Media Server acting as the direct proxy and archive for local IP cameras. In this scenario, all recording occurs at the remote sites and live video streams are viewed by OM Viewers and VM Monitors (video walls) at the headquarters.
In the case of School B, a viewer is installed locally in order to view cameras from the local school. The viewer at School B contacts the Operations Manager for a list of allowed resources (camera feeds/views/archives) and contacts the local Media Server in order to view local cameras. The traffic remains local to the site, unless the viewer selects video from camera feeds at different schools.
Note
Figure 20 Media Servers at Each School
The Media Server at the headquarters could also have parent-child proxies to each remote Media Server and request the remote streams only when required at the headquarters. This would have less bandwidth impact when the same stream is requested by more than one viewer since the traffic would be contained locally in the headquarters LAN.
Cisco 2500 and 4000 Series Cameras
One of the things necessary to consider in the implementation of this solution is the identification of the location of the incident. This was done in multiple ways, using the Augusta EdgeFrontier server as the correlation engine. For camera integration, and motion detection, the camera was used to help identify the location of the camera as well as provide some necessary information for the Augusta server to create the proper notifications. However, not all cameras are created equal. As a result, several different mechanisms were used in this solution.
Cisco 2500 Series Camera
The Cisco 2500 camera has basic communication functionality in the case of an event, which includes FTP and Mail. For this solution, the FTP service was used to connect to the Augusta EdgeFrontier server when an event occurs. Since the Augusta EdgeFrontier server does not support FTP, data could not be moved using full FTP protocols with the server. Rather, data transfer relies on a connection and port established between the camera and the server. Once that connection is established, the Augusta EdgeFrontier server can identify the IP address of the connecting server, and subsequent actions are based on this information.
Additionally, the 2500 camera allows for a schedule in which the notification should or should not occur. This is used as a base functionality to prevent false positives (i.e., motion detected in the hallway during normal school hours should not send a notification).
Cisco 4000 Series Camera
The Cisco 4000 Series camera has similar capabilities as the 2500 Series including the schedule for event notification, but includes one additional function that proved to be useful in this solution. The 4500 includes HTTP notification, and when triggered, performs an HTTP Post function with specific information from the camera itself. The information is in XML format as shown below:
<?xml version="1.0" encoding="UTF-8" ?><DeviceInfo><version>0.0.1</version><EventNotificationAlert><deviceID>1</deviceID><deviceName>Back Hall Camera</deviceName><ipAddress>192.168.32.52</ipAddress><macAddress>00:1E:BD:FC:19:4B</macAddress><dateTime>08242009 11:52:19</dateTime><activePostCount>1</activePostCount><eventType>2</eventType><eventState>1</eventState><eventDescription></eventDescription><DetectionRegionList><DetectionRegionEntry><regionIndex>1</regionIndex><sensitivityLevel>50</sensitivityLevel><detectionThreshold>50</detectionThreshold></DetectionRegionEntry></DetectionRegionList></EventNotificationAlert></DeviceInfo>Knowing where this information comes from and how it is valued provides a mechanism to identify the camera within the event itself. As a result, the devideID was correlated with the soft trigger ID in VSOM. The deviceName provides a way to include the location of the notification in the Singlewire InformaCast message that is dynamically built when a notification occurs. The dateTime of the event is used in the notification as well, which is useful in locating the incident on the video surveillance playback system.
Cisco Unified Communications
In this solution, Cisco Unified Communications is used to provide audio and text notification of alerts and can provide information customized for the specific alert. There is a complete set of APIs and communications mechanisms between Cisco Unified Communication Manager and third-party applications for device monitoring, call control, provisioning, and serviceability. In this solution, Singlewire Informacast communicates with the Cisco Unified Communications System. Communications occur between Singlewire InformaCast and the Cisco Call Control platform (CUCM, CUCME or UC500) and directly between Singlewire InformaCast and the phones. Singlewire InformaCast uses the Computer Telephony Interface - Java Telephony Application Provider (CTI-JTAPI), Administrative XML (AXL), and SNMP to communicate with CUCM and XML and RTP to communicate with the phones. In addition to the standard basic configuration, the latest Cisco JTAPI library must be installed on the Singlewire InformaCast server. This process, as well as the configuration of the call control platforms for all supported versions, is well documented in the Singlewire InformaCast documentation that can be found at the following URL:
http://www.singlewire.com/pdf/InformaCastCME-7.0.pdf
Required TCP/UDP Ports
As with any Cisco Unified Communications deployment, refer to the documentation on the ports required for the particular version of the software being deployed to ensure the network is ready. Ports used specifically for communications between CUCM 7.0 and Singlewire InformaCast 7.0 are 161 for SNMP, TCP 2748 for CTI, and 443 for encrypted communications. Traffic observed between Singlewire InformaCast and the phones include TCP ports 80 and 8081 for phone control. These ports may vary with different versions of code.
IP Multicast
Since IP multicast is used to transport the audio traffic from the Singlewire InformaCast server to the phones, the network should be able to support multicast protocols.
IP Phones
This solution relies on the phones to deliver the audio alert and their text display to provide a text alert. Singlewire InformaCast has the ability to include a graphic display in the alarm. All of the Cisco 7900 series IP phones support the audio playback, XML, and text display. If graphics are desired, some of the lower-end phones have limited or low graphic capabilities. There are no other phone considerations required for this solution.
Other Considerations
Augusta EdgeFrontier Server
The Augusta EdgeFrontier server has various mechanisms that can be used to communicate with other servers, applications, and systems, such as a web method, HTTP call, or TCP requests. Augusta EdgeFrontier is also able to start other applications on command.
By correlating the notifications through the Augusta EdgeFrontier server, the devices have the same connection properties, making support easier for similar device types, provide a greater deal of flexibility, and build in additional security if necessary. This also allows for a single incident to generate multiple responses, rather than configuring a single device to talk to multiple services.
Figure 21 illustrates the correlation capabilities in Augusta for this solution.
Figure 21 Augusta EdgeFrontier Location in the Solution
Augusta EdgeFrontier Notifications to Singlewire InformaCast
The basic functionality of the Singlewire InformaCast server is to provide audio and text messages to a variety of devices. The easy way to deal with this is to create a message for each possible incident that needed to be reported and call that message from each sensor or camera. Although it may be easy from a flow perspective, it is not so easy to setup or maintain. In this solution, a web method supplied by Singlewire was used. This is similar to initiating a message via the web interface or calling a message using an HTTP post, but instead, it can be called remotely and pass parameters and custom messages based on the incident being reported.
The web method, offers the capability of including various pieces of information in real-time in the messages sent by the Singlewire InformaCast server. The following parameters are available in the sendMessageWithDynamicText web method:
•
•
•
•
•
•
By using a dynamic text mechanism, messages may be built dynamically based on the incident being reported. The Augusta EdgeFrontier server can correlate the information from the device, build the message, and initiate the connection to the Singlewire InformaCast server when the incident occurs. Some of this information comes from the camera or sensor itself, other information is coded in the Augusta EdgeFrontier server.
Video Feeds and Archives
There are numerous ways to create archives for any number of reasons. The real challenge is to identify the need for the archive before actually creating them. Depending on the storage location, camera location, etc. multiple feeds or unnecessary high resolution video results in increased bandwidth, unnecessary archives result in increased storage requirements, etc. Understanding what needs to be retained, for what reason it will be used, and for how long will go a long way in identifying the archive strategy and the storage requirements.
The following is an example strategy:
•
•
•
Another option could be to use multiple streams on the cameras. A standard definition feed could be used for a general-purpose archive to minimize storage, and a high-definition feed for a trigger archive to allow for a higher quality image. However, the 4000 Series camera is not able to dual-stream with a primary feed configured at 1080P, requiring to limit the primary feed to 720P. If the requirements demand a high-resolution image, using a dual-stream is likely not an acceptable configuration.
High Availability
While a mission critical application requires maximum availability, many applications require only fast detection of failure and fast recovery. The Physical Safety for Schools solution provides high availability (HA) suitable for schools and yet keep cost down.
Key considerations include the following:
•
•
•
•
Baseline Architecture
For high availability design for the baseline architecture, refer to the "Building Resilient School Campus Network" section in the School Service Ready Architecture Design Guide (see the"Appendix A—Reference Documents" section for reference).
Augusta EdgeFrontier
An Augusta EdgeFrontier server is located at each location. In this solution, the EgdeFrontier has the following three main functions:
1.
2.
a.
b.
It is also possible to create a hierarchy of Augusta EdgeFrontier servers. A child server could attempt to send a notification to its parent server, and if not available, be configured to send its notification to an alternate server.
For this solution, CPAM was configured to send an HTTP request to both the Augusta EdgeFrontier server at the school and the Augusta EdgeFrontier servers at the district office. Since both local Augusta EdgeFrontier and central Augusta EdgeFrontier have the same policy (upon receiving CPAM request, trigger Singlewire InformaCast), Singlewire InformaCast will send out two copies of messages.
3.
Video Surveillance
Cameras at each site are monitored by the Augusta EdgeFrontier server on the same site. When a camera stops responding, the Augusta EdgeFrontier application will trigger Singlewire InformaCast to send notification about the camera failure.
A media server is placed at each school in order to reduce the amount of traffic traversing the MAN. The media server can be configured to store video on a backup server in case the primary media server fails.
While VSOM does not currently support high availability features, it does not affect the key functionality of this application deployment guide. First, Augusta EdgeFrontier will monitor VSOM. If VSOM is not responding, Augusta EdgeFrontier will trigger Singlewire InformaCast to send notification about the VSOM failure. Second, Augusta EdgeFrontier queues a message, such as "VSOM needs to archive the video from camera 1 in School 1 from 11pm to 11:06pm." Upon VSOM coming online, Augusta EdgeFrontier will retransmit this message. Since the media server at School 1 has the video stored typically for a week, it is not a problem that VSOM request the archive of a short video at the moment or some time later.
Physical Access Control
The CPAM server can have a redundant CPAM server in a Linux HA mode so that if the primary server fails, a redundant server is available to continue operations.
However, if CPAM fails or the WAN connection goes down, the Cisco Physical Access Gateway continues providing normal card reader access. Also, the gateway will be able to perform the device I/O rules even without CPAM. Therefore, a door forced open or door held open event can cause an output alarm to be triggered on the gateway locally. However, today no other input alarms from the gateway, such as a glass break sensor or duress signal, can trigger the output alarm locally. It would require going back to the CPAM server to arbitrate. Release 1.2, scheduled by December 2009, will allow any input alarms to trigger the local output alarm using the device I/O rules similar to the door forced open example.
Notification
When triggered by the Augusta EdgeFrontier application, Singlewire InformaCast server will send notification to Cisco IP phones and IP-based speakers. If the MAN connection is down or the Cisco Unified Communication Manager (CUCM) in the district office is down, a school with an Singlewire InformaCast server can still send the notification. This is because CUCM is not required for Singlewire InformaCast to broadcast to IP phone(s). Even when a Singlewire InformaCast message is sent to a single phone, it still uses multicast. CUCM only comes into play when InformaCast uses SNMP to find out what phones are there and when recording a message which can be done in advance.
The above is for notification through Singlewire InformaCast. For normal phone conversations, if the MAN connection is down or CUCM in the district office is down, an Integrated Service Router (ISR) at each school will offer Cisco Unified Survivable Remote Site Telephony (SRST).
Implementing and Configuring the Solution
This section is divided into four subsections, corresponding to the components of this solution. Configuration of each component is provided, but the focus is on how the components integrate as a whole. The following tips may accelerate the system implementation:
1.
2.
3.
4.
Cisco Physical Access Control
The Cisco Physical Access Manager was installed at the district office and Cisco physical access gateway was installed at a school. Configuring CPAM and Cisco physical access gateway includes the following three steps.
Step 1
Step 2
Step 3
Time Synchronization
The Network Time Protocol (NTP) is widely used to synchronize clocks of viewers, application server, routers and other network elements with a reliable time source. The Cisco Physical Access Manager relies on NTP to synchronize the time of the server and all of the gateways. When the server and gateways are not synchronized properly, issues occur, such as corruption of the keys passed between the systems.
Establishing Connection Between CPAM and Physical Access Gateway
When configuring physical access control, first configure the CPAM then configure the Physical Access Gateway. The same order also applies when performing software upgrades to these devices. Both devices can be configured through a secure web interface. First access CPAM through its default IP address https://192.168.1.2, then modify its IP address, as shown in Figure 22.
The physical access gateway has two Ethernet ports. The ETH0 port is used for network communication. The ETH1 port is used to connect a PC to the Gateway for configuration and monitoring. First access the physical access gateway through its ETH1 default IP address https://192.168.1.42.
Then modify the ETH0 IP address to the decided value. Finally, specify the IP address of CPAM so the physical access gateway and CPAM can establish connection. Figure 23 shows the IP address configuration on the physical access gateway. It also shows the specification of CPAM address.
Tip
Figure 22 Configure IP address on CPAM
Figure 23 Configure the Physical Access Gateway
Configuring Door Hardware and Access Policies
Once CPAM and the physical access gateway establish connection, use the CPAM client software to configure door hardware and access policies for the physical access gateway. This enables convenient control and monitoring of many physical access gateways through one central interface.
Step 1
a.
b.
Step 2
a.
b.
Figure 24 Hardware Window
Step 3
•
•
•
•
•
Step 4
a.
b.
c.
Step 5
If during a power failure the doors require free egress, the locks used in that location should be configured as fail-safe. This means that power is required to keep the locking mechanism engaged.
Configure CPAM to Send Requests to Augusta EdgeFrontier
A physical access gateway can send HTTP requests directly to an Augusta EdgeFrontier server. The configuration includes configuring a URL action and associating an event to a URL action. Use the following steps to configure a URL action:
Step 1
Step 2
Figure 25 URL Action
To associate an event to a URL action:
Step 1
Step 2
To send multiple notifications for the same event, multiple URL actions may be configured and associate the same event to multiple URL actions.
Figure 26 Associate Forced Entry Incident to a URL Action
Cisco Video Surveillance
Managing Permissions and Rights
The Video Surveillance Operations Manager provides a detailed management and access control to the application, and resources such as servers, camera feeds and archives. In an environment with different schools monitored by multiple users and a single VSOM, the proper access control should be configured for all users.
Figure 27 shows how to define a role for administrators at School 2. The role can be assigned different access to resources at different locations.
Figure 27 Access Roles
Under Admin > Roles > Rights, specify the access rights for the new role. In the example in Figure 28, their role is only allowed access to a single Media Server.
Figure 28 Access Rights to a Role
Figure 29 shows how a user is assigned to the new School 2 Administrator Role. All users must be a member of at least one role and can be a member in up to 100 roles.
Figure 29 User Roles
By assigning the user to the new role, the user can only access one Media Server from the server's list and is unaware of all their servers in the system, as shown in Figure 30.
Figure 30 Server Restrictions
With the combination of Users and Roles, VSOM allows for a granular definition of rights to specific resources. For example, it is possible to have permissions to manage some camera feeds but have no rights to others. This feature becomes attractive in a system with a large number of devices and locations, since VSOM only displays the resources allowed to each user.
Figure 31 shows how the School2 Operator role has limited access to VSOM resources by selecting Admin > Roles > School2 Operator > Permissions in VSOM.
Figure 31 Roles for School2 Operator
Those changes are reflected on the main screen for User1, who is assigned to the School2 Operator role. In Figure 32, User1 has now limited access to VSOM resources and is unaware of devices at other schools.
Figure 32 School2 Operator Admin Page
VSOM supports defining schedules for the different roles, allowing for a flexible and secure management of devices based on the time of day.
Camera/Time Synchronization
In order to keep video synchronization, it is important to maintain the correct time on the servers and cameras. The need for time synchronization becomes apparent when reviewing video from archives and the time stamp becomes critical to the reviewing process.
NTP configuration should be completed before archive recording is configured. NTP should be configured on all cameras, VSMS, and VSOM servers.
For SUSE installations the YaST is used to configure NTP settings. From the server, select Computer > YaST > Network Services >NTP Configuration as shown in Figure 33. On the following screen, specify the NTP servers' IP address.
Figure 33 SUSE NTP Configuration
IP cameras can also be synchronized to the same NTP server. The configuration steps vary by camera type and manufacturer. To configure NTP for a Cisco 2500 IP Camera, click on Setup > Basic Setup and specify the NTP Server Address and Time Zone as shown in Figure 34.
Figure 34 NTP Configuration Cisco 2500 IP Camera
To configure the time settings on a Cisco 4300 IP Camera, click on Network Setup / Time > Use the NTP Server to Update Time and specify the NTP Server Settings and Time Zone.
Viewing Archived and Live video from the District Office
VSOM provides flexible video archive capabilities for all cameras in the system, regardless of their location. For this application deployment guide, archives were stored at each location in order to maximize the bandwidth use across the WAN. With the proper permissions, any user is able to monitor and view archived video from any school.
To create a recurring recording loop under VSOM, select Admin > Archives > Start/Schedule a New Archive and select the camera source. Click Next and define an archive name, frame rate, and for how long to keep in the server, as shown in Figure 35.
Figure 35 Create New Archive
Before clicking Submit, define the Archive Type and recurring parameters. The example in Figure 36 creates a recurring archive for Sunday mornings, from 7:00am to 10:00am.
Figure 36 Specify Archive Type
VSOM offers the option to keep archives for a predefined number of days. After recording is complete, the archive is kept on the server for predefined number of days. In the previous example, the archive is kept for two days after the archive is complete and automatically deleted.
With the use of Child Feeds, VSOM is able to transmit a camera feed to other locations as video is requested. In this application deployment guide, camera feeds are recorded locally at the school, but they can be transmitted to the district office using all lower frame rate in order to save bandwidth.
In the example in Figure 37, an archive has been created at the local Media Server with a frame rate of 20 frames per second. The Media Server will get the video feed directly from the camera and the archive will not generate any traffic to the district office unless archive video is requested.
Figure 37 Local Archive
While VSOM does not provide transcoding capabilities to video streams, a ChildFeed may be configured with the same image quality and lower frame rate in order to reduce bandwidth utilization across the locations.
To create a child feed, select Admin > Camera Feeds > Create a New Child Feed. Figure 38 shows a child feed created from a parent source. The child feed will be reduced to three frames per second, reducing the bandwidth requirements between locations.
Figure 38 Child Feed
Setting Up Video Surveillance Operations Manager for Motion Detection
Configure the camera feeds to match the camera setup and verify access to the camera through the Operations Manager. Once this step is complete, triggers for motion detection may be configured.
From the Administration screen in VSOM, complete the following steps:
Step 1
Step 2
a.
b.
c.
d.
e.
f.
g.
Once submitted, a new screen will display with the Enable Soft Trigger selected, with a URL that is used to permit external programs to trigger events. At the end of the URL, there is an ID=xx, where xx is the number of the soft trigger. This number should be used when configuring the 4000 Series camera under the Basic Setup >ID field tab. For the 2500 Series cameras, this number is used when configuring the Augusta EdgeFrontier trigger for motion. See Figure 39 for an example of the URL from VSOM.
Figure 39 VSOM Event Configuration
Step 3
Figure 40 VSOM Event Archive Configuration
For this solution testing, the following were specified:
•
•
•
•
Setting Up the 2500 Camera for Motion Detection
There are multiple configuration options for the 2500 Series camera. This section only deals with those options that are relevant to the solution.
Basic Setup is minimal. The most important value on the Basic Setup screen is the use of the NTP server to manage the time on the camera. If time is not synchronized, finding incidents in the VSOM console becomes difficult.
Under the Administration menu, create a user for the VSMS server to access the camera with Administrator access.
Under the Audio/Video > Video, the following settings were used in the test environment:
•
•
•
•
•
•
Step 1
Figure 41 Cisco 2500 FTP Configuration
•
•
•
•
Step 2
Figure 42 Cisco 2500 Motion Detection Setup
Step 3
Step 4
Figure 43 Cisco 2500 Schedule and Trigger Event Setup
Step 5
a.
b.
c.
Setting Up the 4000 Series Camera for Motion Detection
There are multiple configuration options for the 4000 Series camera. This section only deals with those options that are relevant to the solution.
Step 1
Step 2
Step 3
•
•
•
Step 4
•
•
Step 5
•
•
•
•
•
Step 6
a.
b.
Step 7
Figure 44 Cisco 4000 Series Event and Schedule setup
a.
b.
c.
d.
e.
f.
Step 8
Figure 45 Cisco 4500 Series Motion Detection Setup
a.
b.
At this point, you can select each individual box and adjust the sensitivity settings for each selection, or, select Full Screen mode.
Cisco Unified Communications
This solution relies on the Singlewire InformaCast application communicating with Cisco Unified Communications Manager and the phones. The Cisco Unified Communications system must be configured to support that communications. Below are the configurations required for the various call control platforms.
Cisco Unified Communications Manager
On the CUCM cluster, the following must be configured:
Step 1
Step 2
Step 3
Step 4
Older versions of CUCM require the "Include Encoding Information in AXL response" to be set to true.
Singlewire InformaCast only supports G.711µ, therefore, if the system uses other codecs, you must create a region and calling search space with G.711µ as the codec.
The configuration required for each version of supported CUCM software is well documented in the Singlewire InformaCast documentation, so it will not be replicated here. The Singlewire InformaCast documentation can be found at the following URL:
http://www.singlewire.com/s_informacast.html
Cisco Unified Communications Manager Express
In order for Singlewire InformaCast to communicate with CUCME via XML, first the router must be configured to:
•
•
•
Finally, in CUCME the phone URLs must be configured for use with Singlewire InformaCast.
This process is thoroughly documented in the Singlewire InformaCast documentation referenced above.
Partner Products Setup
Following are the detailed steps required to implement the various use cases on Singlewire InformaCast and Augusta EdgeFrontier. The two applications should be properly installed and the basic configuration completed as outlined in the applications' installation guides.
Figure 46 shows a sample signal flow of what occurs when an alarm is triggered.
Figure 46 Sample Event Trigger Signal Flow
Singlewire InformaCast
On Singlewire InformaCast, configure groups for each unique user group. In this example, two groups were configured using instructions of the document at the following document:
http://www.singlewire.com/pdf/InformaCastCME-7.0.pdd.
These were a Security group consisting of the wireless phones, and a Classroom group consisting of the hard wired phones. The group number is required so the Augusta EdgeFrontier system can direct messages to the appropriate phone. This number can be determined by selecting Edit Recipient Groups from the main Singlewire InformaCast administrative page and moving the mouse over the Edit button. See Figure 47. The broadcast group is -1.
In this system, a single message using Text to Speech is configured. The text and recipient group are dynamically changed by the SOAP message from Augusta EdgeFrontier.
Step 1
Step 2
Figure 47 Add Message
Step 3
Step 4
Figure 48 Specify Audio Setting of the Message
a.
b.
Step 5
Figure 49 Script Setting
a.
b.
Figure 50 Create Replacement Message
a.
b.
c.
d.
Figure 51 Messages
Since Singlewire InformaCast uses multicast to send audio to the phones, multicast must be enabled in the network. Refer to the appropriate switch documentation to determine the requirements and the configuration.
Augusta EdgeFrontier
In general, Augusta EdgeFrontier will gather information from the sensor or camera sending the alert and take actions based on that device. Under certain circumstances (i.e., SNMP alerts), the message associated with the various alarms will be looked up on the Augusta EdgeFrontier server and communicated to Singlewire InformaCast. Once communicated to Singlewire InformaCast, the message may be text, audio, or both.
The Augusta EdgeFrontier server has several sections that require configuration. Additionally, certain values or sections requiring configuration will change based on changes made in other sections. For instance, if Series is selected as an Input parameter, the drop down list will only show values for series already created. This dynamic change makes it very easy to select the proper values and minimizes problems that may occur because of mis-typed values. As a result, creating components in a particular order is sometimes required.
Not all components are required to be created uniquely for each particular use case. For example, it is only necessary to create a single communications component for sending messages to Singlewire InformaCast. By valuing the fields properly before calling that method, it is possible to send unique messages using the same communications component.
The Augusta EdgeFrontier deployment section is organized such that most steps are in order so that a required step is completed prior to the subsequent step, but some configuration components have been grouped together for organizational purposes. For readability, the order of sections is organized as follows:
•
•
•
•
•
•
•
Create the Lookup Table Required for SNMP traps
The lookup table required for the SNMP interface is stored on the Augusta EdgeFrontier server and must be loaded at system initialization. See Figure 52 for the steps necessary to perform the initialization.
Figure 52 Lookup Table Initialization Flow
A series must be created to store the message that will be received indicating a fire alarm. A second series must be created to store the messages that will be played as audio when a fire alarm is received. These will be stored in files, so begin by creating a file reader.
Step 1
Figure 53 Add File Reader
Step 2
Figure 54 File Reader Text File
The first field in the line is the value to be matched. Alarm1 is the text value the Fire Alarm will send in an HTTP get parameter. That should be followed by a comma and the text that should be played by Singlewire InformaCast when the alarm is triggered. This text will be sent to Singlewire InformaCast and displayed as a text on the phone and as audio over the phone's speaker.
Figure 55 Add Series
Step 3
Step 4
Figure 56 Add Field
Change the Field Name to AlarmID. This will hold the value that will match the Value parameter in the trap. Ensure the Datatype is String.
Step 5
a.
b.
c.
d.
e.
Figure 57 Add Action
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Figure 58 Add Event
Step 12
Configure the Required Data Communications Components
Step 1
Step 2
Figure 59 Add SNMP Client
The following table lists the setting for Figure 59.
Step 3
Figure 60 Add Web Method
The following table lists the setting for Figure 60:
Step 4
Figure 61 Add HTTP Server
The following table lists the setting for Figure 61.
HTTP Server Name
IP Address
Port
System Web Access
HTTPTriggerServer
Localhost
81
True
Step 5
Figure 62 HTTP Source
The following table lists the setting for Figure 62:
HTTP Source Name
Enabled
Virtual Directory
HTTPTriggerSource
True
/
Step 6
Figure 63 Add Data Communications
The following table lists the setting for Figure 63:
Step 7
Figure 64 Add HTTP Server
The following table lists the settings for Figure 64:
Step 8
Figure 65 Add HTTP Source
The following table lists the settings for Figure 65:
Smoke Alarm
The smoke alarm system generates an SMNP trap with a value in a specific leaf node in the smoke alarm system MIB. For testing purposes, the snmpSetSerialNo was used in the SNMPv2 MIB. See Figure 66.
Figure 66 SNMP MIB Used for Testing
Figure 67 shows the flow for a smoke alarm trap.
Figure 67 Smoke Alarm Flow
Step 1
Figure 68 Add Data Structure
The following table lists the settings for Figure 68:
Step 2
Figure 69 Add Field
The following table lists the settings for Figure 69:
Value
String
Column
RequestID
Int32
Column
ObjectIdentifier
String
Column
Step 3
Figure 70 Add Row Event
The following table lists the settings for Figure 70:
Step 4
Figure 71 Add Condition
The following table lists the settings for Figure 71:
NoOIDmatch
ObjectIdentifier
CustomValue
Trap's OID
True
Step 5
Figure 72 Add Variable
The following table lists the settings for Figure 72:
HoldRowIndex
Int32
AlarmMessage
String
Group
Int64
Step 6
•
•
•
Details are shown in Figure 73.
Figure 73 Add Action
The following table lists the settings for Figure 73:
Step 7
Regions are optional in the configuration, but allow for improved readability of the system by grouping. Figure 74 shows a region with a name related to the smoke alarm settings (SmokeDetectedPolicy).
Figure 74 Add Region
Step 8
Step 9
Figure 75 Add Event
The following table lists the settings for Figure 75:
SmokeDetected
Series
SmokeAlarms
RowAdded
Policy
SmokeDetected
Step 10
Figure 76 Add Action
The following table lists the settings for Figure 76:
SendMsgToInformaCast
SmokeDetected
Web Method
Group
Invoke(Params)
Step 11
Fire Detection
The fire alarm system generates an HTTP Get with a parameter named Event on port 81. That value is arbitrary. Use the same port configured by the fired alarm system.
Figure 77 shows the data flow for a fire alarm.
Figure 77 Fire Alarm Flow
Step 1
Figure 78 Add Series —FireAlarms
The following table lists the settings for Figure 78:
Step 2
Figure 79 Add Field - Fire Event
The following table lists the settings for Figure 79
Step 3
Figure 80 Add Action - Fire Alarm
The following table lists the settings for Figure 80:
Step 4
Step 5
Figure 81 Add Policy - FireDetected
Step 6
Step 7
Figure 82 Add Policy to SendMsgToInformaCast
The following table lists the settings for Figure 82:
SendMsgToInformaCast
SmokeDetected,FireDetected
Web Method
InformaCastNotify
Step 8
Figure 83 Add Event - Fire Detected
The following table lists the settings for Figure 83:
FireDetected
Series
FireAlarms
RowAdded
Policy
FireDetected
Motion Detection with a Cisco 2500 Camera
The data flow for the Cisco 2500 Series camera is shown in Figure 84.
Figure 84 Motion Detection with 2500 Series Camera
Step 1
Figure 85 Add Series
The following table lists the settings for Figure 85:
Step 2
Figure 86 Add Fields to Series
The following table lists the settings for Figure 86:
Step 3
Figure 87 Add Row Event
The following table lists the settings for Figure 87:
Step 4
Figure 88 Add Condition
The following table lists the settings for Figure 88:
Step 5
Figure 89 Add Variables
The following table lists the settings for Figure 89:
Step 6
Figure 90 Add 2500 Actions
The following tables list the settings for Figure 90:
Step 7
Figure 91 Add Specific 2500 Camera Actions
The following tables list the settings for Figure 91:
Location_Back_Hall
Motion_192_168_32_50
1
Series
True
Motion2500 (Relates to Motion2500 Series)
SetSeriesFieldLastValue(FieldName, Value)
Send_VSOM_Back_Hall
Motion_192_168_32_50
1
HTTP Client
True
VSOM_Comms (refers to Data Communications entry for VSOM
Execute(NewURI)
NewURI
Custom
Blank
http://ipaddr/vsom/service/event_notify.php?id=13
Replace ipaddr with VSOM IP address
Replace id=13 with actual soft trigger id for this camera
Build_IC_Back_Hall
Motion_192_168_32_50
2
Template Text
Variable
InformaCast_Template_2500 (Refers to variable field created)
Blank
String
InformaCast_Msg_Out_2500
(Refers to variable field created to hold InformaCast Msg)
Send_IC_Back_Hall
Motion_192_168_32_50
3
Web Method
True
InformaCast_Dynamic_Msg
(Refers to the Method created communicating with InformaCast Server
Invoke([Params])
Step 8
See Figure 92 and the table that follows for details.
Figure 92 Add 2500 Events
The following table list the settings for Figure 92:
Motion Detection with a Cisco 4000 Series Camera
Figure 93 shows the flow of data with the 4000 Series camera.
Figure 93 Motion Detection with 4000 Series Camera
Step 1
Figure 94 Add Series
The following table list the settings for Figure 94:
Step 2
Figure 95 Add Fields to Series
The following tables list the settings for Figure 95:
Step 3
Figure 96 Add Row Event
The following table list the settings for Figure 96:
Step 4
Figure 97 Add Condition
The following table list the settings for Figure 97:
Motion
Custom Value
Blank
None
Equals
False
Step 5
Figure 98 Add Variables
The following table list the settings for Figure 98:
InformaCast_Template_4500
String
Motion has been detected on the @field:MotionDetected.deviceName@ at @field:CameraDateTime.CameraTime@ on @field:CameraDateTime.CameraMonth@/@field:CameraDateTime.CameraDay@.
The Default value uses substitution parameters to insert values into the message. Format of the parameter is:
@keyword:SeriesName.FieldName@
InformaCast_Msg_Out_4500
String
Leave Blank
VSOM_MSG_IN_4500
String
http://192.168.200.2/vsom/service/event_notify.php?id=deviceID
An action will occur that will change the deviceID value to that contained in the xml string submitted by the camera
VSOM_MSG_OUT_4500
String
Blank
Holds the convertes VSOM Message
Step 6
Figure 99 Add 4500 Motion Event
The following table list the settings for Figure 99:
Motion_Detected_4500
Row Event
True
CameraDateTime.Motion_Detected
RowEventFired
Policy
Policy name for the Motion_4500 action
Step 7
Figure 100 Add 4000 Series Camera Actions
The following tables list the settings for Figure 100:
Build_VSOM_Msg
Motion_4500
1
Build_IC_Msg
Motion_4500
1
VSOM_Notification_4500
Motion_4500
2
HTTP Client
True
VSOM_Comms
(references Data Communications entry for VSOM)
Execute(NewURI)
IC_Notification_4500
Motion_4500
2
Web Method
True
InformaCast_Dynamic_Msg
(References the Method created for communicating with InformaCast Server)
Invoke([Params])
Notifications to Augusta EdgeFrontier Based on Time of Day
Augusta EdgeFrontier may be configured to recognize events from IP cameras and, based on the time of the day, trigger an event for VSOM. For example, for some video cameras, recording can be disabled between 6:00am and 6:00pm, when school activity is at its highest and enabled at all other times. Maintenance periods can also be configured follow the same guidelines.
Step 1
Figure 101 Evening Hours Schedule
The following table list the settings for Figure 101:
MorningHours
Daily
06:00AMs
1
Evening Hours
Daily
06:00PM
1
Step 2
Figure 102 OperatingHours Series
The following table list the settings for Figure 102:
OperatingHours
String
Element
Custom
Variable("OperatingHours")
Step 3
Figure 103 OperatingHours Variable
The following table list the settings for Figure 103:
OperatingHours
String
Morning
ASCII
LittleEndian
Step 4
Figure 104 Row Events for AfterHours
The following table list the settings for Figure 104:
Step 5
Figure 105 After Hours Event
The following table list the settings for Figure 105:
Step 6
Figure 106 ScheduleFired
The following table list the settings for Figure 106:
Step 7
Figure 107 Variable Set
The following table list the settings for Figure 107:
To define other time periods, such as the maintenance window, follow the same steps specifying a different Scheduler fire time.
Lab and Test Overview
Test Overview
The test goals were to simulate a school environment with different locations and diverse requirements. The emphasis was on configuring different devices to generate events and provide the intelligence to integrate those security events with a correlation engine capable of communicating with different, such as Singlewire InformaCast or the Cisco Video Surveillance Manager.
The lab environment includes a district office and different schools. The goal of the district office was to centralize as much as possible the video surveillance, access control, and the Unified Communications servers. By centralizing the main applications, the deployment scenarios are simplified at the school level.
This application deployment guide testing did not focus on testing Layer-2 or Layer-3 features typical of a campus or branch office deployment, since those have been extensively documented in other solutions.
Figure 108 shows the five different locations configured for the test environment.
Figure 108 Lab Environment
Cisco Video Surveillance
A single Cisco video Surveillance Operations Manager server was deployed at the district office in order to manage the Media Servers deployed at the schools. A single VSOM server is capable of managing cameras, events and media servers located at different schools. The Media Servers were also deployed locally at each school in order to archive video from local cameras and to reduce bandwidth requirements across the MAN.
Each Media Server acts as a proxy to the local IP cameras and possible viewers. Video can still be viewed by any location if required and the proper user permissions are in place.
School 2 and School 3 are directly connected to the District Office while School 4 and School 5 are completely standalone. The Cisco ISR router in School 4 is responsible for providing voice gateway capabilities, routing within the school, and for hosting the Video Management and Storage Module (VMSS). School 4 and 5 provide event messaging between Singlewire InformaCast, Augusta EdgeFrontier, and the Cisco Unified Communications. School 5 does not include video surveillance devices.
Figure 109 shows the interaction between the VSOM at the district office and a three Media Servers local to the district office, School 2, and School 3. The VSOM provides proper access to all cameras and provides a consistent interface for all of viewers.
Figure 109 also shows how viewers are deployed at each location and how cameras interface with the local VSMS which acts like a proxy for live and archived video.
Figure 109 Cisco Video Surveillance
Cisco Physical Access Control
A single CPAM server was deployed at the district office to manage the access gateways at different schools. An access gateway and door hardware were installed at School 2. Since the testing focused on on integrating different components, rather than scalability, access gateways were not installed at each school. The door hardware includes a card reader, a lock, a door sensor, a button used to request for exit, and an alarm. Using forced entry as an example, the access gateway reports the incident to CPAM, CPAM notifies EdegeFrontier, and Augusta EdgeFrontier triggers VSOM and Singlewire InformaCast. These interactions are shown in Figure 110.
Augusta EdgeFrontier and Singlewire InformaCast
An Augusta EdgeFrontier engine was deployed at each school location in order to provide localized device configuration and processing of alarms and events. Each Augusta EdgeFrontier engine received alarms from IP cameras, access control systems, and fire and smoke detection systems.
Based on the alarm type, notifications were sent to VSOM, Singlewire InformaCast, or CPAM and in turn those systems acted according to predefined actions, such as paging, video archiving, etc.
Figure 110 shows the interaction between these systems and how Augusta EdgeFrontier receives alarms at each location.
Figure 110 Augusta EdgeFrontier Interaction
Hardware/Software
Table 1 and Table 2 show the different devices and releases used during the solution testing.
Appendix A—Reference Documents
•
http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns826/landing_srArchit_edu.html
Cisco Physical Access Control
•
•
Cisco Video Surveillance
•
http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6918/ps9692/ps7307/data_sheet_c78-455613.html
•
http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6918/ps9692/ps9716/data_sheet_c78-492032.html
•
http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns819/landing_vid_surveillance.html
•
http://www.cisco.com/en/US/products/ps9153/products_user_guide_list.html
•
http://www.cisco.com/en/US/products/ps9152/products_user_guide_list.html
•
http://www.cisco.com/en/US/docs/video/cvmss/rel1_1/installation/guide/cvmssinst.html
Cisco Unified Communications
•
http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_installation_guides_list.html
•
http://www.cisco.com/en/US/products/sw/voicesw/ps4625/prod_installation_guides_list.html
Partner Products
•
http://www.singlewire.com/informacast.html
•
http://www.singlewire.com/s_informacast.html
•
http://www.augustasystems.com/Products/Overview.htm
Physical Safety for Schools Application Deployment Guide
Feedback