# Emergency Alert and Response

Call Telemetry is an enhancement to existing compliance solutions. It can discover live data about the phone, caller, or calling party, and build a context of data available for alert templates. Sources could be CSV, HTTP APIs, and Meraki API to add more location information to alerts. Wire mapping tools also support Network Admin teams like our QR Code Wire Mapping for Cisco, saving labor of wire mapping buildings for phones.

# Solution Overview

# Requirements

  • Premium License
  • CUCM version (SU3) or higher.
    • Versions bellow this can still get 911 notifications but without location.

# What if I have Cisco Emergency Responder, or similiar?

Keep your solution, but you can use Call Telemetry to build more context for your existing solutions.

# Installing with Cisco Emergency Responder

Attach the ECC / CURRI Profile for Call Telemetry onto your 911 pattern, or CTI ports for Emergency Responder. CER continues to do the ELIN transformations, and Call Telemetry gives you more location and alert workflows.

# What can you discover?

  • CUCM Device information
    • Model, Description, CUCM Location, etc.
  • Phone Details
    • CDP/LLDP, Subnet Mask
  • Traceroute to next hop
    • Identify phone as an MRA or VPN connected device
  • CSV Data about the Subnet - Any fields you want to provide
  • HTTP API Webhooks Response containing further location information for use in variables
  • Meraki API - Location of device in Meraki Org for location context

# High Level Overview of Realtime Discovery


# Alert Templates

Alerts can contain variables that are replaced with the actual values at runtime. Variables are enclosed in double curly braces. This tree allows you to visualize the variables available to you in the alert template. You can use any of the variables in the template, and they will be replaced with the actual values at runtime.

Alerts are covered in more detail under Alerts


# Example Data Context:

Here's an example payload available after a successful discovery. You can use any of these fields in custom alerts or apps. You can also query APIs to build in more data to this context.

"event": {
"called_number": "1001",
"calling_devicename": "SEP000832C78E0F",
"calling_number": "231",
"id": 21331,
"trigger_point_type": "translation_pattern"
"final": {
"action": "permit",
"modifiers": {
"calledname": null,
"callednumber": null,
"callingname": null,
"callingnumber": null
"reason": "permit rule",
"rule": {
"name": "test3",
"greeting_enabled": false,
"greeting_name": "Jason",
"calling_number": ".*",
"called_number": "1001",
"policy_action": "permit"
"phone": {
"description": "Demo Phone - Room 101",
"device_name": "SEP000832C78E0F",
"device_pool": "Default",
"extension": "1001",
"firmware": "",
"ip": "",
"location": {
"address": {
"name": "Home",
"address1": "1234 Main St",
"address2": null,
"city": "Fairhope",
"state": "AL",
"zip": "36532"
"address_text": "1234 Main St Fairhope,AL 36532",
"match": "port",
"near": "IDF-Room101 Floor 1, NE Corner of Building.",
"port": {
"name": "GigabitEthernet1/0/15"
"switch": {
"name": "Switch",
"location": "IDF-Room101 Floor 1, NE Corner of Building.",
"ip": ""
"model": "Cisco 7821",
"neighbor": {
"neighbor_ip": "",
"neighbor_name": "Switch",
"neighbor_port": "GigabitEthernet1/0/15"
"next_hop": {
"fqdn": "Switch",
"hostname": "Switch",
"ip": "",
"output": null
"ris_data": {
"ActiveLoadID": "sip78xx.14-1-1-0001-136",
"Description": "Demo Phone - Room 101",
"DirNumber": "1001",
"IPv4": "",
"Model": "Cisco 7821",
"Name": "SEP000832C78E0F",
"Status": "Registered",
"StatusReason": "0"
"status": "Registered",
"status_reason": "",
"subnet": {
"ip_with_cidr": "",
"subnet": "",
"subnet_base": "",
"subnet_prefix": "24"
"policy": {
"name": "test",
"api_key": "950bd6e7-5555-5555-5555-bfcf9bfd73ab"
Last Updated: 9/23/2023, 1:52:56 AM