Varios teléfonos Cisco no pudieron registrarse como dispositivos HELD (base de datos de ubicación de emergencia alojada) con el servicio Redsky E911 después de una migración de ubicación. Los dispositivos afectados anunciaban direcciones IPv6 e IPv4 y, a pesar de agregar intervalos IPv6 a la configuración de confianza IP y realizar reinicios de dispositivos, varios teléfonos seguían sin registrar. Además, los intentos de eliminar la solicitud de dispositivo HELD de Redsky y de reiniciar los teléfonos en Webex Calling no resolvieron los errores de registro de todos los dispositivos.
Entre los dispositivos específicos con problemas de registro se incluyen:
BC:AB:F5:DA:44:A5 (IPv6: 2620:107:9098:403:beab:f5ff:feda:44a5)
BC:AB:F5:DA:40:9D (IPv6: 2620:107:9098:403:beab:f5ff:feda:409d)
BC:AB:F5:DA:20:CD (IPv6: 2620:107:9098:403:beab:f5ff:feda:20cd)
BC:AB:F5:DA:4D:E4 (IPv6: 2620:107:9098:403:beab:f5ff:feda:4de4)
AC:7E:8A:B7:D0:35 (IPv6: 2620:107:9098:404:ae7e:8aff:feb7:d035)
BC:AB:F5:DA:47:90 (IPv6: 2620:107:9098:405:beab:f5ff:feda:4790)
7C:62:E7:CF:A1:3C (IPv6: 2620:107:9098:405:7e62:e7ff:fecf:a13c)
BC:AB:F5:DA:44:CC (IPv6: 2620:107:9098:4405:beab:f5ff:feda:44cc)
Implementación de Cisco Webex Calling con integración del servicio E911
Plataforma de servicio Redsky E911 para servicios de ubicación de emergencia
Varios teléfonos IP de Cisco en una configuración de red de pila doble (IPv4/IPv6)
Migración reciente de la ubicación que requiere la funcionalidad del servicio E911 para todos los dispositivos
Teléfonos configurados con direcciones IPv4 e IPv6
La resolución implicaba identificar y configurar los rangos de subred interna que faltaban en la configuración del portal Redsky para habilitar la detección y el registro adecuados de los dispositivos.
El usuario confirmó el método de detección que se utilizará en la nueva ubicación. El método de detección de intervalos IP es el método seleccionado, por lo tanto, debe validar que los intervalos de IP pública y local utilizados por los dispositivos se configuraron en el portal RedSky.
La investigación reveló que las subredes internas específicas utilizadas por los dispositivos (validadas en IP locales y públicas del concentrador de control) no se incluyeron en la configuración de Redsky, lo que impidió la detección y el registro adecuados de los teléfonos como dispositivos en espera.
Se identificó que faltaban estos intervalos de IP internos en la configuración del portal Redsky:
10.46.253.103
10.46.254.10
Las subredes internas y los rangos de IP privada que faltaban se agregaron a la configuración de Redsky para habilitar la detección y el registro adecuados de los dispositivos.
Después de agregar los rangos de IP privada que faltaban a la configuración de Redsky, todos los dispositivos afectados se reiniciaron para activar un nuevo intento de registro con el servicio E911.
Tras la actualización de la configuración y el reinicio del dispositivo, todos los dispositivos que fallaban anteriormente se registraron correctamente como dispositivos en espera en el portal Redsky, lo que restauró la funcionalidad E911 para la ubicación.
Los errores de registro fueron causados por una configuración de subred interna incompleta en el portal de servicio Redsky E911. El sistema Redsky requiere que todas las subredes internas e intervalos de IP privada que utilizan los teléfonos se configuren explícitamente en el portal para la detección y el registro adecuados de los dispositivos. Cuando los teléfonos intentaron registrarse desde rangos de IP no incluidos en la configuración de Redsky, el proceso de registro falló a pesar de que los dispositivos estaban correctamente configurados para la red de doble pila y tenían direcciones IPv6 válidas. La configuración de doble pila de los dispositivos contribuyó, ya que los teléfonos anunciaban direcciones IPv4 e IPv6, pero la configuración de subred interna que faltaba impidió un registro correcto independientemente de la versión de IP utilizada.
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
10-Nov-2026
|
Versión inicial |