HIDE THIS SLIDE - INSTRUCTIONS There is a small ICON in the TOP LEFT CORNER of each slide that looks like this: This ICON is set to appear automatically after the LAST build in the slide and is designed to to indicate to the presenter the END of the slide builds for that slide. If you add animations, make sure you move this to the END of the animation list for the slide. If there are NO animations on the slide, like this slide, the graphic will appear immediately.

Enterprise NG911 Now Using an Over the Top Architecture Tim Kenyon, ENP Mark J. Fletcher, ENP President / CEO Chief Architect – Worldwide Conveyant Systems, Inc. Public Safety Solutions - AVAYA

Who I am . . . and why you should care Tim Kenyon, ENP President / CEO Conveyant Systems, Inc. Nortel / Avaya OEM Partner PC Attendant Consoles Embedded WLAN 8100 E911 Avaya Internal E911 Solution Our Public Safety Industry Firsts: 1st Avaya E911 Select Product 1st Avaya IP Office SNMP Compliant 1st Avaya Internal Solution 1st HTML Based Alert Content Mark J. Fletcher, ENP Chief Architect AVAYA Public Safety Solutions FCC Disability Advisory Committee APCO Standards Definition Committee NENA Institute Board Member 7 US Patents for Public Safety related technology The Reality of the ‘Over The Top’ Model NOT about ALI Database Management Today’s ALI has useless additional data NG 911 replaces PS-ALI with Additional Data Reality is PSAPs rarely view or consider the information beyond the street address as valid REAL-TIME data is possible NOW via OTT

1968 The Problem What’s the number for 911?

The solution was to build an Emergency Telephone Network - BUT Public Safety Agency “A” It was based on 1970’s assumptions Phone Numbers were identities: They were UNIQUE They were SINGLE APPEARANCES They were FIXED LOCATIONS The network knew 3 important things: WHO you were WHERE you were located WHAT agency provided service to you. Citizen 555-1234 SRDB* 555-1234 = Agcy A 555-4567 = Agcy B 555-6789 = Acgy C Telecom Provider Citizen 555-4567 Public Safety Agency “B” SRDB* 555-1234 = Agcy A 555-4567 = Agcy B 555-6789 = Acgy C Citizen 555-6789 Public Safety Agency “C” *Selective Router Data Base

2000 The Problem IP networks introduced MOBILITY

Device Location Discovery (IP Devices) Layer 2 – Switch Port Layer 3 – IP Subnet/Mask Very precise – Zone or Station Requires a valid wire map MAC work must be controlled Less granular – Zone only Easily managed with VLANs Very flexible for user MAC work 192.168.10.0/24 911 ZONE 1 192.168.20.0/12 911 ZONE 2 192.168.30.0/24 911 ZONE 3 192.168.20.13/12 911 ZONE 4 10.10.50.0/24 911 ZONE 5

2016 Today’s NEW Problem Internal and External Public Safety Situational Awareness

SITUATIONAL AWARENESS and the ADR ADR – Additional Data Repository When user endpoints make an emergency call, the location as well as other ‘BIG DATA’ about the incident is relevant and needs to be conveyed to 1st responders and internal staff.

ROUTING – Not difficult if you know the LOCATION Accomplished LOCALLY or via CLOUD Emergency call routing is geographically specific UC Mobility creates additional challenges Wired IP sets moving Virtual Office / Touchdown cubes Work at Home users Nomadic users on Public Networks Routing can be simplified by isolating to a location and dispatchable address Consolidate response to BUILDING Minimizes monthly OPEX Maximizes INTERNAL awareness

Emergency Calling - AWARENESS AVAYA 4655 Great American Parkway Santa Clara, California What PUBLIC SAFETY Responders Need Dispatchable Address What they need to get to the building What INTERNAL Responders Need Everything you can possibly give them Explicit location information Building environmental information heat/sprinklers Floor plans Links to video feeds in the affected area Event indications like an AED removal MSDS and Hazmat information Big Data from the Internet of Things UNFORTUNATELY – NONE OF THIS has ANYTHING to do with the phone system It’s about building an Emergency Response Solution using data already in your network and providing it to Public Safety BIG DATA

THE PBX CANT SEND LOCATION DATA TO THE 911 PSAP What . . . . .?

The problem – The Wrong Solution Public Safety Agency “A” Managing the ANI/ALI database is costly and difficult. This becomes the largest expense for MLTS 9-1-1 Unclear additional info (Cube 2C-231?!) Often not populated Often incorrect information 9-1-1 Telecommunicators have told us that the data found in this 30 character field is simply not reliable or relevant. With the amount of other information coming in, this becomes superfluous and is often ‘lost in translation’. MLTS User 555-1234 BUSINESS – MLTS 555-1234 AVAYA, Inc. 4655 Great American Pkwy 2nd FL Cube 2C-231 Telecom Provider SRDB 555-1234 = Agcy A 555-4567 = Agcy B 555-6789 = Acgy C CLocDB* 555-1234 = Addr A 555-4567 = Addr B 555-6789 = Addr C *Caller Location Data Base

What most people are afraid to admit . . . “Common communications we use every day have eclipsed the capabilities of E9-1-1. UC and mobility allow devices to be anywhere, the phone number is no longer a relevant indicator of location and presence. Using phone numbers for routing is archaic and unreliable, and additionally, there is no way to attach multimedia to the call. We cannot wait for NG9-1-1. Over The Top NG9-1-1 will save lives today.” Mark J. Fletcher, ENP Chief Architect – Avaya Worldwide Public Safety Solutions

Why Most Enterprise E911 Deployments Fail Mass Confusion – What’s needed/required Too Complex – Trying to boil the ocean No Plan – Poor measurement of success The three primary reasons why most enterprising 911 deployments fail are: MASS CONFUSION - administrators simply just don’t understand what is required to solve the problem, or what capabilities the PSAP actually has to determine the location of the caller. TOO COMPLEX - many vendors utilize this lack of understanding at the IT administrator level, to make enterprise E 911 sound complex and difficult to solve. This allows them to extract large budgets for the and implementation, when in reality simple constructs can be put in place that can easily solve the problem at hand NO PLAN - because enterprise IT administrators don’t understand 911, it becomes difficult for them to communicate their requirements for solution. The thinking behind public safety is very specific and driven to a particular solution. IT administrators have a completely different agenda, and have very little exposure to public safety and their requirements. Because all of these, E911 solutions are deployed in a very haphazard manner, without proper design, potentially increasing risk to employees instead of minimizing it.

SENTRY – A New Approach to an Old Problem What is Sentry™? It’s NOT a box. It’s a modular framework designed to provide the functions that are needed to resolve Enterprise E9-1-1 location and notification issues Affordable Only buy the modules you need Simple Deployment costs are low compared to current solutions – yet more functionality VM Based – Flexibility of deployment and resiliency means easy licensing No proprietary hardware or Single Point of Failure appliances Efficient Enhances E9-1-1 capabilities of the PBX Reduce or eliminate PS-ALI / monthly recurring OpEx charges from the LEC Flexible for in building, branch and remote workers This is why we developed SENTRY, the new standard in enterprise E911. SENTRY is a modular framework purpose built to provide the functions that are needed to solve the enterprise E911 location and notification issues. By modularizing the solution, administrators only need to pay for and deploy the specific modules they need in their environment. This keeps the solution simple, and by utilizing virtual machine instances and no proprietary hardware, full resiliency and redundancy becomes part of the deployment, and there’s no reliance on proprietary hardware or single point of failure that are found in many other appliances on the market today. This operational model enhances the capabilities already built into the PBX, and eliminates the use of private switch ALI accounts which create monthly OpEx charges from the LEC. This solution and construct has the flexibility that allows it to provide either building, branch, or support for remote workers within a single solution.

Enterprise Requirements NOW Enterprise Requirements Delivering what is needed NOW

Basic System Requirements - KARI’S LAW Direct access to Emergency Services Eliminating the ‘Trunk Access Code’ (TAC) Alerting to devices that an emergency call has occurred No Interception of calls internally to untrained staff PD Direct access to Emergency Services Eliminating the ‘Trunk Access Code’ (TAC) Alerting to devices that an emergency call has occurred No Interception of calls internally to untrained staff

Capturing Data & Providing Access LDAP Smart Building Enviro Info Cable Mgmt ADR Additional Data Repository Active Directory Opt In Info WLAN User Data PBX User Data Data is packaged ready for pick-up by Public Safety or Designated 1st Responders

Notification to INTERNAL 1st Responders AVAYA 4655 Great American Parkway Santa Clara, California Screen Pop Alert Clients can be anywhere Detailed Floor Plans / Video Zone based Routing and Escalation Correlation of all information available Integration with 3rd Party Smart Buildings Mobile apps, Web based or Reader boards By empowering the Enterprise with information about the incident they can contribute additional data simplifying the call for help.

Workflow for Delivering the Data to Public Safety Direct to 911 unimpeded Device registers on network Location Discovery Initiated Relevant Info Collected Fixed URL: http://E911.mycompany.com Web DMZ Emergency event or trigger occurs Resources are Correlated Context Store Created Bldg Security Fire / EMS

Migration of the Services TOMORROW Ready for tomorrows architecture

THE FUTURE FOR ENTERPRISE PUBLIC SAFETY Breeze™ Dynamic Team Formation Current VM Deployment Future Breeze™ Deployment WebRTC 100% RTU Migration TRACKER LAYER 2 RT Speech SCOUT LAYER 3 BEACON WLAN WebText Mobile Video

Conveyant Sentry Presentation Thank You for your Time . . . Q & A ?