Phone Registration Issues with Redsky E911 Service Due to Missing Internal Subnet Configuration

Issue

Multiple Cisco phones failed to register as HELD (Hosted Emergency Location Database) devices with the Redsky E911 service after a location migration. The affected devices were advertising IPv6 and IPv4 addresses, and despite adding IPv6 ranges to IP Trust settings and performing device reboots, several phones continued to fail registration. Additionally, attempts to delete the device HELD request from Redsky and rebooting phones in Webex Calling did not resolve the registration failures for all devices.

The specific devices experiencing registration issues included:

• BC:AB:F5:DA:44:A5 (IPv6: 2620:107:9098:4403:beab:f5ff:feda:44a5)

• BC:AB:F5:DA:40:9D (IPv6: 2620:107:9098:4403:beab:f5ff:feda:409d)

• BC:AB:F5:DA:20:CD (IPv6: 2620:107:9098:4403:beab:f5ff:feda:20cd)

• BC:AB:F5:DA:4D:E4 (IPv6: 2620:107:9098:4403:beab:f5ff:feda:4de4)

• AC:7E:8A:B7:D0:35 (IPv6: 2620:107:9098:4404:ae7e:8aff:feb7:d035)

• BC:AB:F5:DA:47:90 (IPv6: 2620:107:9098:4405:beab:f5ff:feda:4790)

• 7C:62:E7:CF:A1:3C (IPv6: 2620:107:9098:4405:7e62:e7ff:fecf:a13c)

• BC:AB:F5:DA:44:CC (IPv6: 2620:107:9098:4405:beab:f5ff:feda:44cc)

Environment

• Cisco Webex Calling deployment with E911 service integration

• Redsky E911 service platform for emergency location services

• Multiple Cisco IP phones in a dual-stack (IPv4/IPv6) network configuration

• Recent location migration requiring E911 service functionality for all devices

• Phones configured with both IPv4 and IPv6 addressing

Resolution

The resolution involved identifying and configuring missing internal subnet ranges in the Redsky portal configuration to enable proper device discovery and registration.

Step 1: Investigate Registration Failure

The user confirmed the Discovery Method to be used on the new location. IP range discovery method is the selected method, therefore you need to validate that Public and Local IP ranges used by devices were configured in RedSky portal.

Investigation revealed that specific internal subnets used by the devices (Validated on Control Hub Public and Local IPs) were not included in the Redsky configuration, preventing proper discovery and registration of the phones as HELD devices.

Step 2: Identify Missing Internal Subnets

This internal IP ranges were identified as missing from the Redsky portal configuration:

10.46.253.103
10.46.254.10

Step 3: Add Missing Private IP Ranges

The missing internal subnets and private IP ranges were added to the Redsky configuration to enable proper device discovery and registration.

Step 4: Reboot Affected Devices

After adding the missing private IP ranges to the Redsky configuration, all affected devices were rebooted to trigger a fresh registration attempt with the E911 service.

Step 5: Verify Registration Success

After the configuration update and device reboots, all previously failing devices successfully registered as HELD devices in the Redsky portal, restoring E911 functionality for the location.

Cause

The registration failures were caused by incomplete internal subnet configuration in the Redsky E911 service portal. The Redsky system requires all internal subnets and private IP ranges used by the phones to be explicitly configured in the portal for proper device discovery and registration. When phones attempted to register from IP ranges not included in the Redsky configuration, the registration process failed even though the devices were properly configured for dual-stack networking and had valid IPv6 addresses. The dual-stack configuration of the devices was a contributing factor, as the phones were advertising both IPv4 and IPv6 addresses, but the missing internal subnet configuration prevented successful registration regardless of the IP version used.

Related Content

• Cisco Technical Support & Downloads

Revision History

Revision	Publish Date	Comments
1.0	10-Nov-2026	Initial Release