E911 Emergency Calling with RedSky

This integration provides compliance to Ray Baum Act Phase II. Full compliance for all devices, including mobile devices such as tablets, will be provided by January 2022.

How it Works

The RedSky service provides user location services and a network that routes emergency calls to Public Safety Answering Points (PSAPs) around the US, its territories, and Canada. The service is enabled on a per-location basis. After a location is enabled, emergency calls (911 for emergency calls and 933 for test calls) placed from phones and clients assigned to that location use the RedSky service. The RedSky service does the following:

  • FIND—RedSky finds the user location. Both the Webex App and desk phones send MAC or network information to the RedSky service, which uses a company wiremap to determine the location. For Webex App users, if their location can't be determined, the user is prompted to enter location information, which is then submitted to Redsky.

  • ROUTE—For 911 and 933 calls, the location information is added to the SIP header, which also identifies the user as a Redsky user. RedSky routes the call to the appropriate PSAP for the location.

  • NOTIFY—RedSky sends notifications to the appropriate personnel (e.g., security or emergency services).

RedSky handles the following tasks:

  • RedSky maintains the partner/customer provisioned database that maps an emergency call to a dispatchable location.

  • Based on the calling device's dispatchable location, RedSky directs emergency calls to the correct PSAP. The call includes location information so that the PSAP knows where to dispatch emergency personnel as well as the call-back number.

  • RedSky generates optional notifications to enterprise personnel.

  • For subscriptions with enhanced licenses, RedSky bridges enterprise personnel into emergency calls placed by enterprise users and provides pop notifications.

Location Detection

RedSky supports two main types of location detection: HELD and non-HELD.

  • For HELD-capable devices (the Webex App or multiplatform firmware (MPP) devices)—Location detection is based on network discovery. The HTTP Enabled Location Delivery (HELD) protocol reports network environment information to the RedSky HELD service. This information includes the upstream switch, wireless access points (WAP) BSSID, IP address, or MAC address. Note that MPP devices and the Webex App send HELD information differently as follows:

    • MPP devices use HELD. When the phone registers, it sends an HTTP request to RedSky that includes device network information. The HELD server uses this information to determine location.

    • The Webex App use HELD+. In addition to standard HELD information, the Webex App also sends a user indentifier to RedSky. RedSky uses this information to determine user and device location. If a location is unknown, the Webex App prompts the user to enter the address.

  • For non-HELD capable devices (mobile devices without cellular access, softphone clients, Cisco ATAs, Cisco DECT systems, and any non-Cisco customer premises equipment)—Location determination is based on the Caller ID asserted in the test or emergency call.

PSTN and RedSky Locations-Enabled Routing

BroadWorks routes emergency calls to the RedSky service, so that the call can be sent to the appropriate PSAP, instead of the PSTN. This route gets used for all endpoints that place emergency calls from the RedSky-enabled location. This includes hard phones and portable endpoints (such as mobile phones, tablets, and laptops).

One exception to this rule is for cellular-based phone clients. These clients send emergency calls directly to the Public Land Mobile Network (PLMN, the mobile equivalent of the PSTN) using the built-in dialer on the phone.

Figure 1. PSTN and RedSky Locations-Enabled Routing

Requirements for RedSky E911 Integration

Component

Requirement

RedSky

The partner must enter an agreement with RedSky to route emergency calls using Cisco-provided implementation for Webex App desktop and tablet clients and MPP phones (HELD).

RedSky Configuration

The partner must configure the RedSky portal to provide location services for the following types of devices:

  • Calls from HELD devices that use wiremap information for location determination (MPP phones and the Webex App)

  • Calls from non-HELD devices that use Caller ID for location determination (DECT, ATA, and Room/Desk/Board devices)

For more information, see the following RedSky documentation:

  • RedSky Horizon Mobility Administration Guide—Contains Service Provider responsibilities.

  • RedSky Horizon Mobility User Guide—For enterprise adminstrators. This guide describes how to set up the wiremap.

  • EON Client Installer (Emergency On-Site Notification)—Describes how to set up emergency notifications.

BroadWorks

To use this feature, you must have installed the following BroadWorks patches. Install only the patches that apply to your BroadWorks release:

  • For R22:

    • AP.as.23.0.1075.ap381498

    • AP.xsp.22.0.1123.ap381498

    • AP.platform.22.0.1123.ap381498

  • For R23

    • AP.as.22.0.1123.ap381498

    • AP.xsp.23.0.1075.ap381498

    • AP.platform.23.0.1075.ap381498

    • ADP RI App: CommPilot-23_2021.11_1.160.bwar

  • For R24:

    • AP.as.24.0.944.ap381498

    • ADP RI app: CommPilot-24_2021.11_1.160.bwar

Phones

MPP phones use downloaded configuration parameters to access the RedSky Location Information Server (LIS). They receive a token that gets passed forward over the peering connection to RedSky when a RedSky-enabled user dials 911 or 933.

Devices

HELD capable devices: Once a location is enabled for RedSky services, Cisco BroadWorks device management systems generate updated device configurations to enable HELD functionality. Each HELD device must be re-synced or reinitialized to pick up the new configuration before the device can use HELD for location services.

Webex App

Webex desktop and tablet apps use downloaded configuration parameters to access the RedSky Location Information Server (LIS). Users must enter their location information once per location. RedSky maintains a record of each location. When the user logs in from a new location, they are prompted to enter their location information, which gets added to the database.

When the user places a 911 or 933 call, the geolocation information gets passed in the SIP Header.

Figure 2. Add E911 Address

 
By default, the Webex App prompts users to update their location when logging in at an unknown location. However, the %EMERGENCY_REDSKY_USER_LOCATION_PROMPTING_WXT% configuration tag lets administrators reconfigure the frequency to include any network change to an unknown location. See Webex Client Configuration Tags for Emergency Calling for configuration options.

RedSky E911 Configuration Task Flow

Complete the following tasks on BroadWorks to configure Webex for Cisco BroadWorks for E911 Emergency Calling with RedSky. On BroadWorks, E911 is configured using the Third-Party Emergency Calling feature.

  Command or Action Purpose
1

Activate Feature

Use the CLI to activate feature 101792.
2

Configure Third-Party Calling URLs

Use the CLI to configure settings such as URLs used by RedSky.
3

Check Emergency Dial Strings

Verify the dial strings that BroadWorks uses for Emergency Calling.
4

Configure SIP Header Proxy Rule

On the Application Server, configure a SIP Header proxy rule.
5

Configure Third-Party Emergency Calling (Enterprise/Service Provider Service)

On CommPilot, configure the Enterprise service for Third-Party Emergency Calling.
6

Configure Third-Party Emergency Calling (Group Service)

On CommPilot, configure the Group service for Third-Party Emergency Calling.

Activate Feature

On the Application Server, run the following CLI command to activate feature 101792.

AS_CLI/System/ActivatableFeature> activate 101792

Configure Third-Party Calling URLs

Use the CLI to configure the AS with Third-Party Emergency Calling parameters such as RedSky URLs.

1

Run the following CLI command to view current parameter settings:

AS_CLI/Service/ThirdPartyEmergencyCalling> get
primaryHELDServerURL= 
secondaryHELDServerURL=
emergencyRouteHost=
emergencyRoutePort=
emergencyRouteTransport=
2

Run the following CLI command to set the parameters. Refer to the subsequent table for information on the fields:

Set
    <attribute>, Multiple Choice = {primaryHELDServerURL, secondaryHELDServerURL, emergencyRouteHost, emergencyRoutePort, emergencyRouteTransport}
    <primaryHELDServerURL>, String {1 to 256 characters}
    <secondaryHELDServerURL>, String {1 to 256 characters} 
    <emergencyRouteHost>, IP address | host | domain (1 to 80 chars)
    <emergencyRoutePort>, Integer {1025 to 65355}
    <emergencyRouteTransport>, Choice = {udp, tcp, tls, unspecified}

See the following table for help with the parameters:

Setting

Description

Primary HELD Server URL

This parameter defines the primary URL for the HELD server. This parameter cannot be cleared if there is any enterprise in the system allow third-party emergency calling activation. The valid value for this parameter is a string with length between 1 to 256 characters. It should be a valid http or https URL. There is no default value.

Secondary HELD Server URL

This parameter defines the secondary URL for the HELD server. This field cannot be same as the primary HELD server URL. The valid value for this parameter is a string with length between 1 to 256 characters. It should be a valid http or https URL. There is no default value.

Emergency Route Host

This parameter defines the emergency route host address. The value for this parameter should be a valid FQDN, IPv4 address, or IPv6 address. This parameter cannot be cleared if there is any enterprise in the system that allows third-party emergency calling activation. There is no default value.

Emergency Route Port

This parameter defines the emergency route port. The valid value for the parameter is an integer between 1025 to 65355. There is no default value.

Emergency Route Transport

This parameter defines the emergency route transport protocol. The possible values for this parameter are:

  • UDP

  • TCP

  • TLS

  • Unspecified—This is the default value

Check Emergency Dial Strings

1

On the AS, run the following CLI command to verify the dial strings that are being used for emergency callings. Note that 933 should be included in addition to 911. The 933 prefix is used for test calls. 

AS_CLI/System/CallP/CallTypes> get

  Country Code  Digit Map  Call Type  
  ==================================
   	1       1911 	Emergency  
   	1        911 	Emergency  
   	1        933 	Emergency
2

If you need to add dial strings, use the following command: 

AS_CLI/System/CallP/CallTypes> add <countryCode> <publicDigitMap> <callType>

 
For detailed information on these CLI commands, see Cisco BroadWorks Application Server Command Line Interface Administration Guide.

Configure SIP Header Proxy Rule

On the Application Server, configure a SIP Header rule in conjunction with the RedSky HELD servers. This is required so that the AS can proxy the geolocation and geolocation-routing SIP headers to the RedSky SIP servers.

1

Run the following CLI commands to set the keepOnEgressNetworkOffNet flag set to true.

AS_CLI/Interface/SIP/ProxyPolicy/Rule> add redsky911 false false false true false false false false

AS_CLI/Interface/SIP/ProxyPolicy/Rule> add redsky911 false false false true false false false false
2

Run the following CLI commands to add the SIP headers to that rule:

AS_CLI/Interface/SIP/ProxyPolicy/HeaderPolicy> add geolocation redsky911

AS_CLI/Interface/SIP/ProxyPolicy/HeaderPolicy> add geolocation-routing redsky911

Configure Third-Party Emergency Calling (Enterprise/Service Provider Service)

Configure Third-Party Emergency Calling settings at the Enterprise level.

Before you begin

Make sure that you understand which provisioning model you are using as the Customer ID and Secret Key configurations depend on the model:

  • Enterprise provisioning model—The customer organization is an enterprise. Different groups, such as different sites, fall within the enterprise.

  • Service Provider provisioning model—The goup is a customer organization. Different groups under the Service Provider are unrelated to one another.

1

On Comm Pilot Services window, select Third-Party Emergency Calling.

2

Check the Allow Activation check box.

3

Enter values for the Customer ID and Secret Key fields, depending on which provisioning model you run:

  • Enterprise provisioning model—Enter the values that RedSky provided.

  • Service Provider provisioning model—Enter dummy values (your Group configuration in the next task overrides these values).
4

Click OK.


 
You can also configure these settings automatically by a back-office system using this command: ServiceProviderThirdPartyEmergencyCallingModify.

 
If you are configuring emergency calling for a Service Provider's own organization (rather than customer organizations that the Service Provider manages), use the Enterprise provisioning model and add a unique Customer ID and Secret Key for the Service Provider's own organization.

Field

Description

Allow Activation

This parameter defines if third-party emergency calling can be activated for the groups within the enterprise. Valid value for this parameter is true and false. Default value is false.

If system-level HELD server URL is not specified or emergency route info is not configured, activation is not allowed at enterprise level.

Customer ID

This parameter defines the RedSky customer ID that is used in the third-party emergency call service. This value is unique to a specific customer organization that is managed by a Service Provider. The maximum length for this parameter is 36 characters. If Allow Activation is true, the Customer ID cannot be empty.

Assign the value that corresponds to which provisioning model you run:

  • Enterprise model—Enter the value that RedSky provides.

  • Service Provider model—Enter a dummy value (your Group Service setting overrides this value).

Secret Key

This parameter defines the unique RedSky secret key that is used by the enterprise (as defined by Customer ID) in the Third-Party Emergency Calling service. The secret key format is alphanumeric, UTF-8. This field is mandatory when the Customer ID is defined.

Assign the value that corresponds to which provisioning model you run:

  • Enterprise model—Enter the value that RedSky provides.

  • Service Provider model—Enter a dummy value (your Group Service setting overrides this value).

Configure Third-Party Emergency Calling (Group Service)

If you are using the Service Provider provisioning model, configure Third-Party Emergency Calling that appears under Group Services.

Before you begin

Make sure that you understand which provisioning model you are using as the Customer ID and Secret Key configurations depend on the model:

  • Enterprise provisioning model—The customer organization is an enterprise. Different groups, such as different sites, fall within the enterprise.

  • Service Provider provisioning model—The goup is a customer organization. Different groups under the Service Provider are unrelated to one another.

For the Group Profile settings, the Country must be USA or CAN (for Canada).

1

On the Comm Pilot Group Services window, select Third-Party Emergency Calling.

2

Check both of the following check boxes:

  • Enable Third-Party Emergency Calling Device Management

  • Enable Third-Party Emergency Calling Routing
3

Enter the appropriate Customer ID and Secret Key values for this group according to your provisioning model:

  • Enterprise provisioning model—Leave the fields blank. The values in the previous Enterprise Service procedure get applied.

  • Service Provider provisioning model—Enter the values that RedSky provided.
4

Click OK.

See the following table for help with the fields.

Field

Description

Enable Third-Party Emergency Calling Device Management

This parameter specifies if third-party emergency calling device management is enabled for the group. This parameter cannot be enabled if enterprise level does not allow activation. This parameter cannot be disabled when group third-party emergency routing is enabled. Valid values for this parameter are true (checked) and false (unchecked). The default value is false.

Enable Third-Party Emergency Calling Routing

This parameter specifies if third-party emergency calling routing is enabled for the group. Routing cannot be enabled if enterprise level does not allow activation. Routing cannot be enabled if third-party emergency device management is not enabled.

The valid values for this parameter are true (checked) and false (unchecked). The default value is false.

Customer ID

This parameter defines the RedSky customer ID that is used in the Third-Party Emergency Calling service. This value is unique to a specific customer organization that is managed by the Service Provider. The maximum length for this parameter is 36 characters. If the Group Service Customer ID is not defined, the enterprise/service provider level Customer ID will be used.

Assign the value that corresponds to the provisioning model that you use:

  • Enterprise model—Leave this field blank. The value from the Enterprise Service procedure gets applied.

  • Service Provider model—Enter the value that RedSky provides.

Secret Key

This parameter defines the RedSky secret key that is used with the Third-Party Emergency Calling service. This key is unique to the group (as defined by Customer ID) and uses an alphanumeric UTF-8 format. This field is mandatory if the Customer ID is defined. If the secret key is not defined, the enterprise/service provider level secret key will be used.

Assign the value that corresponds to the provisioning model that you use:

  • Enterprise model—Leave this field blank. The value from the Enterprise Service procedure gets applied.

  • Service Provider model—Enter the value that RedSky provides.

Webex Client Configuration Tags for Emergency Calling

Dynamic Tags

The following table summarizes the dynamic Webex DMS tags that appear in the Webex client configuration file (config.wxt-xml) and how they get derived dynamically from the BroadWorks configuration.


These are “built-in dynamic” tags, not custom tags that are directly created and populated by administrator.

Tag

Data Source

%BWE911-PRIMARY-HELDURL%

AS_CLI/Service/ThirdPartyEmergencyCalling> primaryHELDServerURL

%BWE911-SECONDARY-HELDURL%

AS_CLI/Service/ThirdPartyEmergencyCalling> secondaryHELDServerURL

%BWE911-EMERGENCY-NUMBER-LIST%

AS_CLI/System/CallP/CallTypes> Digit Map values marked as “Emergency”


 

To use this tag, the %RESERVEDBWE911-EMERGENCY-NUMBER-LIST% reserved custom tag must be added to a tag set used by the device type. The reserved tag must contain the emergency numbers defined under AS_CLI/System/CallP/CallTypes> in a comma separated format such as 911, 0911, 933.

Note that the Webex App does not support wildcards in emergency numbers. Only exact emergency numbers should be added to the reserved custom tag.

The following example shows how the reserved tag functionality is meant to be used:

  1. The native tag %BWE911-EMERGENCY-NUMBER-LIST% is added to the template file of a device.

  2. The reserved custom tag %RESERVEDBWE911-EMERGENCY-NUMBER-LIST% is added in a tag set used by the device with the value 911, 1911, 933.

  3. When the file is rebuilt, the %BWE911-EMERGENCY-NUMBER-LIST% native tag is resolved to 911, 1911, 933.

%BWE911-CUSTOMERID%

Configured Group Customer ID if not empty, otherwise SP/Enterprise configured ID

%BWE911-SECRETKEY%

Configured Group Secret Key if not empty, otherwise SP/Enterprise Secret Key

Custom Tags

Following is a list of Webex App desktop and tablet custom tags for emergency calling. Please refer to the Webex for Cisco BroadWorks Configuration Guide for additional details:

%ENABLE_EMERGENCY_DIALING_WXT%

  • Description: Enables Emergency Calls detections

  • Values: [true|false]

  • Default value: false

%EMERGENCY_DIALING_ENABLE_REDSKY_WXT%

  • Description: Enable Redsky Emergency Location Platform

  • Values: [true|false]

  • Default value: false

%EMERGENCY_REDSKY_USER_LOCATION_PROMPTING_WXT%

  • Description: Defines the E911 location prompting behavior. The "aggressive" value shows the dialog to the user on each network change to an unknown location. The "once_per_login" value shows the dialog only while logging in at an unknown location, preventing further popups and distractions for the user.

  • Values: [aggressive|once_per_login]

  • Default value: once_per_login

%EMERGENCY_REDSKY_USER_MANDATORY_LOCATION_WXT%

  • Description: The times that the user is allowed to close the location dialog before location becomes mandatory. A value of -1 allows the user to close the dialog indefinitely.

  • Values: [-1 - 100]

  • Default value: -1

%EMERGENCY_REDSKY_USER_REMINDER_TIMEOUT_WXT%

  • Description: The timeout in minutes that will be used to reminder the user to update the emergency location if the current one is not entered or is invalid. If 0 is set, there will be no reminders.

  • Values: [0 - 43200]

  • Default value: 0

Change History

Change

Details

April 25, 2022

Added Country requirement to Group Service configuration.

March 23, 2022

Added wildcard restriction to %BWE911-EMERGENCY-NUMBER-LIST% tag information.

March 21, 2022

Added Note with info on requirements for the %BWE911-EMERGENCY-NUMBER-LIST% native tag.

March 14, 2022

Added new config tag, %EMERGENCY_REDSKY_USER_LOCATION_PROMPTING_WXT%, which lets administrators edit the location update frequency.