Cisco Notifi-Ed Solution for School Safety and Security Application Deployment Guide
Available Languages
Table Of Contents
Cisco Notifi-Ed Solution for School Safety and Security Application Deployment Guide
Cisco Unified Communications Manager and IP Phones
Solution Features and Benefits
Solution Architecture Framework
Central Management of Solution Components
Survivable Remote Site Telephony (SRST)
High Availability Considerations
Cisco Unified Communications (UC)
Configuring InformaCast and CUCM to Talk to Each Other
Integrating InformaCast and SchoolMessenger
SchoolMessenger High Availability
Appendix A—Management of Router and Switch Configurations
Appendix B—Security Management
Appendix C—Netformx DesignXpert Supported Design
Cisco Notifi-Ed Solution for School Safety and Security Application Deployment Guide
May 15, 2009
Contents
About the Guide
This application deployment guide describes the benefits and features of the Cisco Notifi-Ed solution and details on how to implement the solution in a typical school district architecture. It explains the network architecture that was built in the lab to represent a typical school district and the testing performed to validate how the Cisco Notifi-Ed solution should be deployed on top of that network architecture.
Target Audience
The target users for this application deployment guide are school districts that want to use the Cisco Unified Communications for mission-critical services beyond basic IP telephony and sales engineers who are helping them plan and deploy these communications technologies and services. Some of these education accounts may also be focused specifically on improving safety and security for their staff and students by expediting communications through the school district and the parent community and minimizing response time during emergencies. It is assumed that the administrators of the Notifi-Ed solution have experience with installing the Cisco Unified Communications Manager and Cisco IP phones as well as basic configuration of Cisco routers and switches.
Other users of this guide include the following:
•
Grant writers for schools
•
•
•
About the Authors
Solution Overview
Executive Summary
Schools today are expected to provide the highest level of safety and security to their student population as the community has become accustomed to hearing about violence and threats on school grounds—ranging from bomb threats to student shootings. Parents demand that school districts be prepared to respond effectively to such critical emergencies; therefore, it is ever more important for school districts to optimize their communication technologies in preparation for such disasters. As school districts plan to discontinue their legacy analog telephony systems and migrate to IP telephony, they are already looking ahead at what additional applications and network configurations they must add to their network to end up with a communications platform that is scalable, highly-available, automatable, and supports functions including voicemail, paging, bells/alarms, and announcement broadcasting. Whether it is to install IP telephony for the first time on their network or whether it is to evaluate the benefit of an upgrade to their existing system, school districts are first evaluating whether they can leverage their IP telephony network to deliver critical services to faculty and students before making major investments.
The Cisco Notifi-Ed solution for School Safety and Security is a Cisco Validated Design (CVD) that provides school districts with an integrated communications system for rapid mass and audience-specific message broadcasting. The solution demonstrates how the Cisco Unified Communications can be used by Reliance Communication's SchoolMessenger system and Singlewire's InformaCast product to deliver rapid communications to school administrators, teachers, students, and parents through audio, Register for Text Messages (SMS) text, and email and to receive and log acknowledgements from message recipients, a critical function in emergency situations where school districts must be sure that parents have received announcements about the well-being of their children. The Cisco Notifi-Ed can be used to send emergency communication as well as daily operational announcements to the broader community that consists of parents, school district administrators, school faculty, students, and law enforcement.
The following are examples of how the Cisco Notifi-Ed solution can be used in non-emergency and emergency situations to give timely notification to teachers, students, and parents.
•
•
Target Market
The U.S. School Education environment is undergoing a significant transformation today where technological innovation is not only employed to augment the learning process, but also to optimize school operations and heighten the awareness of, and responsiveness to, safety and security concerns that affect our schools and their respective districts.
With 97,000 public schools spread across 18,000 districts, with an additional 35,000 private schools, educating a combined 56,000,000+ students nation-wide, the U.S. School Education environment is extremely vast and must be able to adapt with agility to maintain educational excellence on a global scale, keeping pace with the next-generation education environment.
In addition, given the opportunity to request one-time grants through newer programs such as economic stimulus funding and more traditional programs such as Erate, schools must be able to invest the one-time grants in technologies that will not require them to hire additional headcount for ongoing system maintenance. They must invest in technologies that are easy to deploy, manage, and scale.
Schools require a quick way to notify part or all of its parents and employees by telephone, and/or email, and/ or SMS, and/or in-school paging, in the event of an emergency and to place routine calls concerning local school meetings, attendance, and other announcements concerning school operations.
By partnering with SchoolMessenger and Singlewire, IT departments garner buying and funding dollars from other functions including:
•
•
•
•
•
These additional decision-makers, combined with increased cost savings for district's outreach programs helps IT departments secure the support they need to adopt new information technologies and deploy IP Telephony in the classroom for teachers.
Solution Description
Every day, the administrators and teachers of school districts strive to provide the best education possible to all students, in the safest environment possible. Unfortunately, many of the communication tools they use today hinder their productivity. Traditionally, school district's communications consist of inefficient paper-based practices, outdated phone systems—such as older PBX (private branch exchange), centrex, or key systems with limited features—site-based paging and auto-dial configurations, and analog speaker systems, all running on a network that does not support additional technologies like video surveillance and digital signage.
These discrete and outdated systems make it difficult for administrators, teachers, and staff to be productive and work efficiently. They may spend excessive time driving between locations, lose paperwork, and have to engage in sessions of phone tag—all of which can lead to frustration and job dissatisfaction. Plus, these outdated systems cost a significant amount of money to operate because they often require separate personnel to supervise and maintain. Worse yet, they might also have a more serious effect like delaying the response to an emergency situation and the broadcasting of information to the parent community.
The Cisco Notifi-Ed solution is designed to improve communications for school districts. By using the Cisco Unified Communications infrastructure and proven network designs, along with leading industry applications from partners Singlewire and SchoolMessenger, the Notifi-Ed solution provides a dynamic collaboration platform for safety and security as well as administrative efficiency, effective teaching, and next-generation learning.
Cisco Unified Communications Manager and IP Phones
The Cisco Unified Communications is a powerful, IP-based communications system that uses your existing data network to provide new, advanced communication services, such as voice, video, and web collaboration to help ensure that your district is communicating in the most effective and efficient manner possible. IP-based communication services improve district wide communications, safety, and productivity, all while offering significant cost savings.
The Cisco Unified IP phones are not like regular phones. They provide better communications, make schools and districts safer, and improve the business of education. They can be installed either with wired or wireless in classrooms, offices, and common areas. With IP phones, it is easy to:
•
•
•
•
•
•
•
•
With a Cisco Unified IP phone in every classroom, it is easy for a teacher to get help if a problem occurs. There's no need to leave students unattended in order to contact another teacher or the office. Instead, teachers can simply place a call using their IP phones. In the event of an emergency, each teacher can access first responders with the touch of a button The support of wireless as well as wired IP phones allows mobility through the school grounds- particular useful in schools where security personnel roam the halls or where teachers move from classroom to classroom. With wireless IP phones, they can be certain to receive emergency notification wherever they might be and will be able to respond immediately by triggering a SchoolMessenger or InformaCast message broadcast.
The Notifi-Ed solution enhances safety by enabling staff to:•
•
•
•
•
Table 1 highlights the main features and benefits of the Notifi-Ed solution as well as the features and benefits of the partner applications Singlewire InformaCast and SchoolMessenger that are used in the solution.
Whether communicating casual details like the time and location of a campus-wide assembly or notifying the educational community at large with evacuation instructions for a developing incident, you can use your existing data network to meet your needs. By adding the Cisco Unified Communications to your current IP network, you can provide:
•
•
•
•
•
•
Table 2 lists and describes the features for the partner products used in the Cisco Notifi-Ed solution.
For further information about the Cisco Unified Communications, refer to the following URL:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/uc7_0.html
Solution Components Overview
Rapid communications for mass or audience-specific notification is delivered in Notifi-Ed through the integration of the following Cisco Unified Communications products and Cisco Technology Partner products:
•
•
•
•
•
The Notifi-Ed solution was validated in a representative school district network that was based on the Schools Service-Ready Architecture. The Schools Service-Ready architecture was defined by the Cisco Education System and Campus Enterprise Solutions Engineers working in collaboration to identify the network infrastructure and the application-enabling network services that make up a typical school architecture.
This school district network built in the lab consisted of the following technologies and components:
•
•
•
–
–
–
•
–
–
•
–
–
•
–
–
Solution Features and Benefits
The Notifi-Ed solution provides school districts with a message notification system that is easy to deploy, centralized at the district office, remotely manageable, scalable, and highly-available.
Most school districts with legacy systems run separate paging, bell, and clock systems at each school in the district. There is no way to update these systems or centrally manage any of them. Changes to clocks, paging zones, or bell schedules require a site visit by someone in the Facilities department or a paid contractor. The system cannot be updated without buying a new system.
The InformaCast centrally manages all paging, bells, and clocks. There is no limit to the number of zones or the size of the zones. Clocks are always accurate and changes to bell schedules can be made by any authorized person from anywhere, so that facilities personnel are no longer required to go to the physical location of the clocks and bells to check the status of the unit or make adjustments to parameters like volume. For new construction, the InformaCast and IP speakers are 50 percent of the cost of an analog system. Since the system is software-based, it can be updated over time. In addition, the IP speakers support Power-over- Ethernet (PoE), providing significant cost savings during deployment as additional electrical wiring is not required.
Similarly, the SchoolMessenger Flex Appliance is deployed centrally at the district office and provides message notification services to all the school locations in that district.
The followin are common questions that come up when discussing centralizing services on a location such as the district office:
Q.
Q.
The Cisco Unified Communications is designed to continue operating at a school branch during a WAN outage if Survivable Remote Site Telephony (SRST) is configured on the Integrated Services Router (ISR) deployed at that branch. SRST continues to service IP phones on the LAN when the centrally-deployed Cisco Unified Communications Manager (CUCM) is unreachable and management of IP phones will fall back to the CUCM once the WAN is back up. The SchoolMessenger system is designed to continue providing district-wide and remote message notification services during a WAN outage by sending out mass or audience-specific message notification over the PSTN from the SchoolMessenger-hosted service. During a WAN outage, a user at a school branch can still continue to configure SchoolMessenger jobs through the IVR interface that is accessible from any land-line phone or cell phone. The SchoolMessenger Flex Appliance at the district office works with the hosted service at the SchoolMessenger data center under normal operations when the WAN is available to offload calls to the hosted service as needed.
Many schools have been using PBX or Centrex systems in their districts for traditional "tone" services. IT departments in schools are looking for a more comprehensive business case to justify the migration to IP-based phone services and are investing in applications that provide functionality, cost savings, and benefit to the district beyond their existing systems. The Notifi-Ed solution offers the flexibility and scalability of the Service-Ready Architecture for schools with the integration of partner applications capabilities to address scalability, application, and storage performance challenges with advanced networking, internal and external messaging, and communications technologies. This end-to-end education architecture solution improves messaging best practices and provides the field and partners confidence in partnered messaging applications. Cisco, as a solution provider for unified communications and messaging, provides the most comprehensive messaging solution available in the market today. Combining a proven communications infrastructure with integrated speaker paging, desktop phone visual and audible announcements, SMS text, and automated out-dial announcement and response, Cisco provides an end-to-end solution architecture for enabling additional communication and messaging solutions.
The Notifi-Ed solution supports user workflows that allow school administrators at the district office to make district-wide announcements to all their schools at the touch of a button. The announcements can be pre-recorded to minimize response time for urgent situations such as bomb or gun threats on campus where immediate actions like evacuation are necessary. The announcements can be ad-hoc to allow for the flexibility of spontaneous announcements to suit the situation. Both pre-recorded and ad-hoc messages can also be sent from any school location out to other school sites and the district office.
Both the InformaCast and the SchoolMessenger applications can be managed through a web browser and they both have the added benefit of allowing users to configure and execute jobs from any IP phone that has been minimally configured with that support. Both applications can be integrated together via their SOAP API so that the InformaCast server can be configured to trigger a pre-configured SchoolMessenger job when an InformaCast job is executed. This allows users to send out mass notification to students and faculty on-site as well as parents, students, and staff who are remote all at the same time. This function is especially critical in emergency situations where a large number of people, local or remote, must be notified immediately.
Scope of the Solution
The overall scope of the Notifi-Ed solution is to provide an end-to-end solution architecture for a centralized, highly-available, easily-deployable message notification system that supports both audience-targeted communication as well as mass notification. The solution supports both message notification for daily operations common in a school district as well as emergency notification to students, faculty, parents, and the general public.
The solution includes deployment and configuration of Cisco Unified Communications Manager, IP phones, SchoolMessenger and Singlewire InformaCast services running on top of a network infrastructure that follows the best practices of the Service-Ready Architecture for Schools.
The following network services from the Service-Ready Architecture for Schools falls within the scope of this solution:
•
•
•
•
The devices used in this solution represent what was required to perform functional testing. The implementation of this solution requires proper sizing of the various devices based on the individual needs of the customer.
Solution Architecture Framework
The Cisco Services-Oriented Network Architecture (SONA) framework provides a standard paradigm for designing current and next generation solutions that link network-based services with enterprise applications to drive business results. The SONA framework (see Figure 1) illustrates the components of the solution from the infrastructure providing network-based services and the applications that consume them.
Figure 1 SONA Framework
The following is a brief description of the different layers of this architectural framework:
•
•
•
The Cisco Notifi-Ed solution is built using the architectural framework shown in Figure 1, enabling the solution to be developed with the appropriate supporting applications, network services, and network systems. Following this framework ensures that network services are properly integrated to meet the solution requirements. In addition, the framework facilitates the expansion of the solution scope—if applications should be added to the solution moving forward, it will be clear what additional network services and network systems need to be added to support the additional functional requirements.
The design of the Cisco Notifi-Ed solution on such an architectural framework supports the addition of other mission-critical applications and systems that are needed to address the increasing business demands of school districts in the areas of administrative efficiency, safety and security, and next generation learning.
Solution Network Architecture
The network and network services architecture for this solution is based on the design of the School Service-Ready Architecture (see Figure 2).
Figure 2 Service Ready Architecture for Schools
Figure 2 shows the architectural framework for delivering mission-critical services to school and district environments, all on a single network fabric. It can be scaled up or down based on the sizing, bandwidth, and budgetary requirements of the school district. It provides options and best practices for high availability, redundancy, QoS, mobility, and security and enables Unified Communications, Video Surveillance, Digital Media Systems, and other technologies that are key to transforming school districts into next-generation education environments that optimize the academic experience for its students, operate efficiently and save on administrative cost, and protect their student and faculty with the highest level of safety and security.
The Service Ready Architecture for Schools is designed to meet the following requirements of a next-generation education network:
•
•
•
•
Integrate these new services and technical innovations with existing network equipment, protocols, and methods of communication.
The architecture was therefore designed to deliver the network technologies key to satisfying the objectives above:
•
•
•
•
Solution Services
Security Services
The district office in the Notifi-Ed solution includes an Internet connection that provides the SchoolMessenger Flex Appliance connectivity to the hosted SchoolMessenger services at the corporate data centers located in San Jose and Minneapolis. Perimeter security against potential attacks from the public connection at the district office is provided by the Adaptive Security Appliance (ASA). While security and penetration testing falls outside the scope of this solution, the features and best practices offered by the ASA can be implemented with the Notifi-Ed solution to secure the district office Internet connection.
In particular, the ASA can be configured as a stateful firewall, VPN concentrator, and as an intrusion detection and prevention (IDS/IPS) appliance to handle Internet connections securely. The security appliance combines the above functionalities in one device; on some models, the intrusion detection and prevention is delivered on an AIP-SSM module that plugs into the ASA. Multiple security contexts (similar to virtualized firewalls), transparent (Layer 2) firewall or routed (Layer 3) firewall operation, advanced inspection engines, access-control lists (ACLs), and Network Address Translation (NAT), and IPSec or webVPN support are just a few of the features offered.
In deploying the ASA as the Internet firewall at the district office, be sure that TCP port 443 for HTTPS traffic is left open to allow for inbound communication from the SchoolMessenger-hosted service to the Flex Appliance at the district office. In addition, follow these best practices to allow the network to leverage its security features more effectively:
•
•
•
•
•
•
•
Central Management of Solution Components
In a real-world deployment, the number of school branches that must be considered could range from a few to more than a hundred, for the larger school districts. As the number of network infrastructure devices including routers, switches, and wireless access points scale, it is important to implement a central management scheme that supports easy deployment of new configurations and features, supports rapid upgrades, and allows network and system administrators to monitor the health of their network. Broadly, the central management that applies to this solution can be categorized as network management (for example, configuring and maintaining Layer-2 and Layer-3 configurations) and security management (for example, configuring and maintaining ACLs, firewall rules, and IDS/IPS rules). For suggestions of products that can be used for centralized network and security management, refer to "Appendices" section.
Designing the Solution
Figure 3 shows the user workflow supported by the Notifi-Ed solution, whether the user is physically located at the district office or at a school location.
Figure 3 Solution Work Flow
Survivable Remote Site Telephony (SRST)
SRST is configured on the voice gateway ISR in the school site. SRST provides the central CUCM functionality within the local network in the event that the WAN link is down and communication with the CUCM server at the district office is lost. SRST comprises network intelligence integrated into the Cisco IOS Software, which acts as the call processing engine for IP phones located in the school branch during a WAN outage. This solution did not require any additional SRST configuration beyond the standard configuration that is documented in the Cisco Unified Survivable Remote Site Telephone Configuration Guide at at the following URL: http://www.cisco.com/en/US/products/sw/voicesw/ps2169/products_installation_and_configuration_guides_list.html
High Availability Considerations
The goal of a highly-available system is to minimize network and system downtime during a failure in the network. While redundant components and redundant paths in the LAN were included in the solution, redundant WAN links at the school site was not included in this solution because school districts are not likely to invest in a secondary WAN link given that ERATE funding, which is the school districts' primary source of funding for technology, does not cover that expense. As a result, in addition to leveraging the SRST function available in the ISR, this solution relies on the application survivability that is built into the partner application deployments.
Application Survivability
While school districts are typically unwilling to invest in a secondary WAN link for each of their school locations, they still require that mission-critical services are resilient to network outages. It is important that any application features that provide application redundancy and survivability are used in this solution to deliver that resilience. Both SchoolMessenger and InformaCast can be configured to deliver continuing application services during a WAN outage between the school district and school branches.
SchoolMessenger Services
Figure 4 SchoolMessenger Services
Non-Emergency Calls
When a call job is submitted, whether using the web interface, the IP phone interface or the IVR phone interface, the application processes the job request and sends the calls to be processed to the Flex Appliance system. The necessary data is securely transferred using industry standard SSL encryption. Upon receiving the necessary data required to place a call, the Flex Appliance system places the outbound dial request through CUCM via SIP trunk. The results of each call (for example, answered, busy, no answer, etc.) are then sent back to the user account where they can be accessed in real-time. Depending on the call result and the user's account settings, the undelivered messages will be retried at certain intervals.
Emergency Calls
From an end-user's perspective, the steps for sending an emergency call notification are exactly the same as those for sending a non-emergency notification. The only difference is that the job type is specified as an emergency when the job is created. In this case, the system does not attempt to process the calls through the Flex Appliance system; instead all calls are routed through the much larger capacity of the SwiftWave network.
In the case of a WAN outage at at the school district office, all calls (both emergency and non-emergency) can be configured to route through the SwiftWave network; thus, bypassing the need to communicate with the Flex Appliance until the network outage has been resolved.
InformaCast Services
During a WAN outage at the school branch, InformaCast multicasting to IP phones will no longer function. The SchoolMessenger needs to be used in this case. While InformaCast multicasting to the local IP speakers also no longer functions, a software package called PageKom can be installed at the local site to enable manual paging to IP speakers while WAN connectivity is unavailable. PageKom is free software available for download from Singlewire. For more information, refer to the PageKom User Guide at the following URL:
http://phone-xml.Singlewire.com/iptel/download/PageKom/
PageKom uses an Analog Telephone Adapter (ATA) with a traditional analog handset connected to this ATA. An FXS port off of the Grandstream ATA would be configured to provide dial tone while the network connection, if available, on the local network. The software would reside on a server (potentially a local file and print server) at a local site to the IP speakers, but remotely from the centralized InformaCast server. Currently, the use of a Cisco ATA186 one or two-port adapter or a Grandstream ATA is recommended due to the ability to meet the requirements of Section 3.10 in RFC 2833 which describes the encoding for DTMF events.
Additional information about the Grandstream ATA's can be found at the following URL:
http://www.grandstream.com/ata.html
Additional information about RFC 2833 can be found at the following URL:
http://www.faqs.org/rfcs/rfc2833.html
The basic scenario in this model is that the WAN connection between the centralized InformaCast site and the remote site hosting IP speakers has been lost. The need for paging exists and the use of a single handset is recommended for live audio paging. The ability to page to Cisco IP phones will be lost and additional features in InformaCast like pre-recorded messages and the Bell Scheduler will not be available as this is strictly live audio paging to IP speakers. The software has the ability to do zone management to separate IP speakers.
Implementing the Solution
This section explains the implementation of the Notifi-Ed solution, provides relevant configuration, and lists reference documents. The Notifi-Ed solution provides a convenient way to notify multiple people. For example, it frees a teacher from tedious tasks to notify a large number of students, staff, and parents.
The essence of this solution is to make the following three applications work together in a Service Ready School Architecture:
•
•
•
Solution Components
The solution components required for Cisco Notifi-Ed solution span across several key technologies. These technologies, ranging from routing and switching to the Unified Communications and partner application endpoints, are deployed at different locations in the school district network and address the requirements to improve communication flow between school sites, the school district office, and the parent community. Figure 5 shows an overview of the placement of these technologies in the school district network.
Figure 5 Placement of Technologies in the Notifi-Ed Solution
Table 3 to Table 5 list the different components and versions tested in this release of the Notifi-Ed solution.
School District Components
School Branch Components
Partner Components
Table 5 Partner Components
SchoolMessenger Flex Appliance 2009-02-16 22:22:43 (with hosted CommSuite v6.2)
Quad Core Xeon Processor2x6MB Cache, 2.0GHz,2GB memory Dual 73GB 15K RPM Serial-Attach SCSI Drive,
RAID 1
No Operating System Required
(See http://www.schoolmessenger.com/8973452/docs/ for exact hardware specifications)
Cisco 7845
2 x dual core Xeon 3.4Ghz processors
3.5 GB memory
70GB Disk (Raid 5)
Singlewire InformaCast v6.1
Two-way 32-bit Intel Xeon 3.0 GHz
Dual-core
2 GB memory
RAID 1: Two 72 GB disk drives
Windows Server 2003 Version 5.2
Cisco 7845
2 x Dual core Xeon 3.4Ghz processors
3.5 GB memory
70GB disk (Raid 5)
Implementation Considerations
When implementing this solution, it is vital to consider the characteristics of an organization, the network from the perspective of services, locations to add new components, and implementation sequences. This subsection discusses each of these areas.
Unlike private schools, public schools are unified into a school district according to geographic area. This provides economy of scale as services can be installed in a district office and shared by schools within this district. A district office often physically resides with one of its schools. For example, Milpitas Unified School District (in Milpitas, California) has 14 schools (9 elementary schools, 2 middle schools, 2 high schools, and 1 adult education). The Milpitas district office resides at the same location as the adult education school. This results in similarity between the network for a district office and the network for a school, as both support many end devices such as phones and computers.
Network provides services, such as security, wireless, multicast, and QoS. The services that the network can provide are more important than the actual topology or routers/switches deployed. The Cisco Notifi-Ed solution uses multiple services provided by the network. When the network topology changes and routers/switches are replaced, the solution will work fine as long as the set of services are provided by the network.
In this solution, a CUCM server, a SchoolMessenger server, and an InformaCast server were installed at the district office. The services provided by these applications are shared among all the schools in the district. Phones and IP speakers were installed at schools as well as at the district office since a district office often has a school at its location. See Figure 5 for location of application servers and IP devices.
In lab testing, the solution was implemented in following sequence:
1.
2.
3.
Cisco Unified Communications (UC)
With the Cisco UC, all schools are able to call each other over the IP network as well as able to dial 9 to get out the PSTN. In the lab testing, the following setup was used: one CUCM residing in a district office, one ISR at each school, and various types of phones at the district office and schools. The ISR at each school acts as voice gateway in case the school cannot access each CUCM due to WAN connection failure or CUCM failure.
Whether on the same LAN on not, any phone can register to a CUCM as long as it can reach the CUCM over the network. Except for the regional/location-specific parameters for adding a phone, the procedure on CUCM is essentially the same whether the phone is in the district office (same LAN as the CUCM) or at a school (different LAN as the CUCM).
The following is a sample configuration of the port that connects to a phone:
interface GigabitEthernet1/0/34switchport access vlan 48switchport mode accessswitchport voice vlan 49switchport port-security maximum 11switchport port-securityswitchport port-security aging time 2switchport port-security violation restrictswitchport port-security aging type inactivitysrr-queue bandwidth share 10 10 60 20srr-queue bandwidth shape 10 0 0 0queue-set 2priority-queue outmls qos trust device cisco-phonemls qos trust cosauto qos voip cisco-phonespanning-tree portfastspanning-tree bpduguard enableservice-policy input AutoQoS-Police-CiscoPhoneip dhcp snooping limit rate 100endThe configuration of a CUCM is typically done by an UC technician. In a district office or a school, a common scenario is the need to add an additional phone. This can be accomplished through following steps:
Step 1
Step 2
Step 3
SchoolMessenger
Once the Cisco Unified Communications is working, the next step is to bring a SchoolMessenger server into the district office network. The SchoolMessenger server automates repetitive and tedious tasks as well as supports the execution of a high volume tasks. For example, when a teacher wants to notify parents about a problem at the school (such as a breakage in the water main ) or remind parents of upcoming events (such as various state and federal upcoming student testing), he or she only needs to record a message and decide to which pre-defined group of recipients to send the message. The SchoolMessenger makes the calls.
The SchoolMessenger can be deployed in the following three ways:
•
•
•
For the Notifi-Ed solution, the hybrid model is implemented, which is the more popular deployment model. The hybrid model can be considered as a combination of a fully-hosted system during an emergency and a standalone system for non-emergency (see Figure 4).
Because the SchoolMessenger Flex Appliance places calls through CUCM through a SIP trunk, a SIP trunk needs to be configured on the CUCM. The configuration can be divided into the following steps:
Step 1
a.
b.
c.
Step 2
Step 3
Figure 6 The SIP Trunk Configuration from CUCM
Figure 6 show the configuration used for this solution. For step-by-step instructions of performing the configuration, refer to the SchoolMessenger Flex Appliance Product Overview and Installation Guide at the following URL: http://www.schoolmessenger.com/8973452/docs/.
InformaCast
InformaCast is an application for broadcasting to IP devices and is used for mass notification. It knows about all the devices that are registered to a designated CUCM. Since InformaCast communicates with IP devices exclusively, it can fully use the features of the IP network. For example, it can use multicast to ring 15,000 IP phones simultaneously.
Configuring InformaCast and CUCM to Talk to Each Other
InformaCast obtains all the device information from the CUCM through Simple Network Management Protocol (SNMP). InformaCast discovers the registered IP devices from the CUCM and designates that list as "all devices." A user can divide the large device pool into groups; for example, one group for phones for first grade teachers and and another group for phones for second grade teachers. Then the user can select the relevant group to send a message.
For the solution testing, InformaCast was installed on a Windows 2003 virtual machine on an VMWare ESX 3.5 server. The InformaCast server would be located in the district office, on the same local area network as the SchoolMessenger server and CUCM. See Figure 7 and Figure 8.
Figure 7 Configure CUCM to Enable SNMP
Figure 8 Configure InformaCast to Enable SNMP
After installing InformaCast, perform the following four procedures in sequence:
Step 1
Step 2
Step 3
a.
b.
Step 4
For step-by-step instruction to perform the above configuration, refer to the InformaCast™ 6.1 Installation and User Guide for a Cisco CallManager Telephony Environment at following URL:
http://www.singlewire.com/s_informacast.html
Integrating InformaCast and SchoolMessenger
Most of the time, customers use the InformaCast software or the SchoolMessenger software directly. In unique circumstances, such as as an emergency notification, customers want a single interface. They want to be able to "hit one button" at a point when time is critical. To achieve a single interface, InformaCast will launch SchoolMessenger through a script. For example, a community school with 18 campuses integrated InformaCast with SchoolMessenger. During the many storms in 2008, the school was able to send the "School is cancelled today due to inclement weather" message on all connected IP phones using InformaCast and 15,000 students via SMS using SchoolMessenger.
Comparing InformaCast and SchoolMessenger
The InformaCast and SchoolMessenger complement each other. InformaCast's strength includes sending a message to multiple IP devices at the same time through multicast and communicating to other IP-enabled devices (IP speakers, bells, etc) while SchoolMessenger can communicate to non-IP-enabled devices, such as cell phones and land lines. See Table 6 for a comparison of the two applications.
Devices registered to a CUCM will be known to the InformaCast server and be classified as an internal device. Devices not registered to a CUCM (for example, devices that are reachable through PSTN) are classified as an external device.
Because InformaCast application is not limited to local area network, a user can broadcast a message to multiple schools if their phones are registered to the communication manager in the district office.
Adding a Script to Launch SchoolMessenger
InformaCast uses a script to launch SchoolMessenger so that a user can do internal and external notifications through the same interface. On the SchoolMessenger, a repeatable job, such as "notify_parents" message, can be created (see Figure 9). A repeating job is like a template. It does not have the message content. Instead, the message content will come from InformaCast interface. Each time, a user can change the message content; for example, "School is cancelled for Monday, April 27, 2009" from the InformaCast interface. When triggered by InformaCast, SchoolMessenger works according to preset rules, such as "what is the latest time to call" and "how many times to retry".
Figure 9 Setting UP a Repeating Job on SchoolMessenger
In Figure 10, the blue square (see where the arrow is pointing to in the figure) indicates that a script has been selected.
Figure 10 Selecting a Script
For using the integrated interface of SchoolMessenger and InformaCast, the following steps are performed in advance:
Step 1
Step 2
Step 3
Whenever an emergency occurs, the customer only needs to perform Step 3 ( customize the message content, click on Send to send to a group of internal devices and also trigger external notification).
Perform the following steps to specify and run a script:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
http://asp.schoolmessenger.com/ciscocvdtest
While the URL for SOAP requests was as follows:
https://asp.schoolmessenger.com/ciscocvdtest/api/smapi.php
Modifying the Script
InformaCast provides a sample script. The following were modified to reflect the actual installation in lab testing:
1.
2.
3.
4.
InformaCast releases a script builder to make this process convenient.
IP Speakers
IP speakers are connected to the same switch as IP phones. Similar to IP phones, IP speakers receive power from the Power- over-Ethernet (PoE) switch. The port connecting an IP phone has both voice VLAN and data VLAN configured because an IP phone has both a network port and an access port for connecting to the Ethernet cable and to a PC, respectively. On the other hand, the port connecting an IP speaker has only voice VLAN because an IP speaker does not have an access port for connecting to a PC that requires data VLAN.
The configuration of the port connecting to an IP speaker is similar to the configuration of the port connecting to an IP phone, except there is no data VLAN statement:
interface GigabitEthernet1/0/47description IP Speakerswitchport mode accessswitchport voice vlan 49switchport port-security maximum 11switchport port-securityswitchport port-security aging time 2switchport port-security violation restrictswitchport port-security aging type inactivitysrr-queue bandwidth share 10 10 60 20srr-queue bandwidth shape 10 0 0 0queue-set 2priority-queue outmls qos trust device cisco-phonemls qos trust cosauto qos voip cisco-phonespanning-tree portfastspanning-tree bpduguard enableservice-policy input AutoQoS-Police-CiscoPhoneip dhcp snooping limit rate 100endIP speakers obtain configuration from an InformaCast server. IP speakers do not communicate with a CUCM directly. The boot up sequence of an IP speaker has both similarity and difference to the boot up sequence of an IP phone. The steps are as follows:
Step 1
Step 2
Step 3
While its boot up scheme is similar to the boot up of an IP phone, two differences exist:
a.
b.
Step 4
High Availability
Cisco UC, SchoolMessenger, and InformaCast provide high availability in different ways.
UC High Availability
In case CUCM at the district office is not reachable (CUCM failure or WAN goes down), the school site ISR keeps IP phones online using SRST. In the lab testing, when the connection between the district office and a school was shutdown, we were able to call phones within the school as well as outside phones through PSTN.
SchoolMessenger High Availability
Emergency notification is done by fully-hosted, highly availability network. For all notifications, SchoolMessenger retries multiple times according to user configuration.
InformaCast High Availability
In InformaCast, high availability is accomplished through the following two methods:
1.
2.
Quality of Service
Quality-of-service (QoS) is used to treat different types of traffic differently when congestion occurs. For example, during congestion, priority needs to be given to voice traffic over data traffic, since voice, as a class of IP network traffic, has strict requirements concerning packet loss, delay, and delay variation (also known as jitter).
No new QoS policy is applied for SchoolMessenger and InformaCast. Since the main objective is to enable QoS for IP Telephony only, AutoQoS VoIP macro is used to automatically generate the best-practice QoS configuration. For a port connecting to an IP phone, the automatically generated Cisco VoIP configuration is as the following:
srr-queue bandwidth share 10 10 60 20srr-queue bandwidth shape 10 0 0 0queue-set 2priority-queue outmls qos trust device cisco-phonemls qos trust cosbauto qos voip cisco-phoneservice-policy input AutoQoS-Police-CiscoPhoneFor detailed information on AutoQoS VoIP, refer to the Enterprise QoS Solution Reference Network Design Guide Version 3.3 that can be found at the following URL: http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book.html
Multicast
Multicast feature avoids sending duplicate information on the network. When the user sends the message "Please implement emergency evacuation procedure immediately: this is not a drill " to the 50 IP phones in a school from the InformaCast server in the district office, there is only one copy of this message over the WAN to the school.
PIM sparse mode is configured on each router interface and multicast routing is enabled globally to support multicast traffic for InformaCast audio messages. Because the WAN is Metro Ethernet, multicast can be routed over the WAN without further encapsulation or tunneling.
For a router to participate in multicast, first enable multicast globally on the router, then enable multicast for each interface that has an IP address, whether it is a physical interface or a virtual interface.
The following is an example configuration for the router in the district office:
Global configuration:
ip multicast-routingip pim rp-address 10.33.9.1ip pim spt-threshold infinityConfiguration for each interface with an IP address:
interface FastEthernet5/2ip pim sparse-modeFigure 11 shows the multicast address used by the InformaCast application.
Figure 11 Multicast Setting on InformaCast
Many applications use multicast features to decrease the bandwidth usage of the WAN. In the lab, the following were tested:
•
•
For this implementation, recommended campus multicast design was used. For details, refer to the Cisco AVVID Network Infrastructure IP Multicast Design SRND at the following URL: http://www.cisco.com/application/pdf/en/us/guest/tech/tk363/c1501/ccmigration_09186a008015e7cc.pdf
Appendices
Appendix A—Management of Router and Switch Configurations
For the Notifi-Ed solution, CiscoWorks LAN Management Server (LMS) can be used to configure and manage the Layer-2 and Layer-3 configurations on the ISR and the Catalyst switches. CiscoWorks LMS can be deployed at the district office and managed remotely through a web browser.
Table 7 describes the composition of applications within LAN Management Solution 3.1.
Appendix B—Security Management
The Cisco Security Manager can be used to manage security on the school branch and district office infrastructure devices. While there is only one branch and one district office implemented in the validation of the Notifi-Ed solution, the implementation and design guidance developed in this solution is applicable to larger-scale networks.
Cisco Security Manager is suitable for efficiently managing networks that range from a few devices to thousands of devices. Scalability is achieved through powerful policy-based management techniques, which allow settings to be defined once and then optionally assigning the settings to individual devices, groups of devices, or across the enterprise. When a setting is changed, Cisco Security Manager automatically applies the change to all affected network devices. The firewall or VPN policies are platform-neutral, and can be applied across different device platforms such as Cisco routers, security appliances, or services modules. Cisco Security Manager also provides flexible device-level overrides; this allows policy re-use and sharing while retaining the ability to customize device-specific settings as necessary.
While the deployment of the Cisco Security Manager was outside the scope of solution validation, the following link provides more information on how to deploy the Cisco Security Manager for your network:
http://www.cisco.com/en/US/docs/security/security_management/cisco_security_manager/security_manager/3.1/user/guide/ug31.html
Appendix C—Netformx DesignXpert Supported Design
The Notifi-Ed solution has been incorporated into the Netformx DesignXpert library updates. Using Netformx, sample solution designs and bill-of-materials can be referenced and, if needed, can be modified to fit the specific deployment scenario required for a given healthcare organization. Over time, when the need to update the design becomes necessary, the Netformx updater mechanism automatically downloads the Cisco verified solution blueprints and corresponding part numbers that comprise the solution to all Netformx subscribers.
The Cisco Industry Solution Engineering team has partnered with Netformx to offer its solution designs in the DesignXpert quoting tool. By using Netformx DesignXpert, quoting a solution becomes significantly simplified, increases productivity, and helps eliminate missed components—promoting customer satisfaction. DesignXpert helps you and your customer establish a validated solution blueprint that becomes a reliable reference source for managing the overall life cycle of the solutions.
More information about the Netformx DesignXpert is available at the following URL:
Cisco Validated Design
The Cisco Validated Design Program consists of systems and solutions designed, tested, and documented to facilitate faster, more reliable, and more predictable customer deployments. For more information visit www.cisco.com/go/validateddesigns.
ALL DESIGNS, SPECIFICATIONS, STATEMENTS, INFORMATION, AND RECOMMENDATIONS (COLLECTIVELY, "DESIGNS") IN THIS MANUAL ARE PRESENTED "AS IS," WITH ALL FAULTS. CISCO AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THE DESIGNS, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
THE DESIGNS ARE SUBJECT TO CHANGE WITHOUT NOTICE. USERS ARE SOLELY RESPONSIBLE FOR THEIR APPLICATION OF THE DESIGNS. THE DESIGNS DO NOT CONSTITUTE THE TECHNICAL OR OTHER PROFESSIONAL ADVICE OF CISCO, ITS SUPPLIERS OR PARTNERS. USERS SHOULD CONSULT THEIR OWN TECHNICAL ADVISORS BEFORE IMPLEMENTING THE DESIGNS. RESULTS MAY VARY DEPENDING ON FACTORS NOT TESTED BY CISCO.
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers, Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, The Fastest Way to Increase Your Internet Quotient, and TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0711R)
Feedback