La versión corta
Durante décadas, una llamada al 911 fue un circuito de voz dirigido por un enrutador selectivo, y la dirección de quien llamaba se buscaba después en una base de datos aparte. El 911 de próxima generación (NG911 en EE. UU., NG9-1-1 en Canadá) lo reemplaza con redes IP operadas para los servicios de emergencia, un enrutamiento de llamadas basado en la ubicación de quien llama y una ubicación que viaja dentro de la propia señalización de la llamada. Para un sistema telefónico de empresa, la transición cambia tres cosas:
- Cómo su proveedor entrega la llamada. El tráfico al 911 va a la autoridad de 911 en SIP, en los puntos de entrega que la autoridad designa, en lugar de pasar por troncales heredadas hacia un enrutador selectivo.1
- Cómo viaja la ubicación. En la segunda fase de la regla estadounidense, la ubicación va "embedded in the call signaling using Presence Information Data Format—Location Object (PIDF-LO) or the functional equivalent" (incorporada en la señalización de la llamada mediante PIDF-LO o su equivalente funcional), y el proveedor debe usar un Servidor de Información de Ubicación (LIS) para verificar los registros de ubicación de sus clientes.1
- Qué puede enviar quien llama. Las redes están diseñadas para texto, datos y, con el tiempo, video, no solo para voz.2024
Las fechas difieren según el país. En EE. UU., las reglas de 2024 de la FCC no fijan una fecha nacional de cambio: cada autoridad de 911 activa sus propios plazos con una "valid request" (solicitud válida), y el proveedor tiene entonces seis o doce meses por fase, según su tipo.1 En Canadá, el CRTC fijó una sola fecha nacional: las redes heredadas E9-1-1 deben desmantelarse a más tardar el 31 de marzo de 2027, y a partir de entonces "only NG9-1-1 calls will be delivered" (solo se entregarán llamadas NG9-1-1).23
Lo que NG911 no cambia es quién responde por los datos de ubicación de usted: si la dirección registrada para un teléfono de escritorio, una aplicación telefónica o una extensión alojada es incorrecta, NG911 entrega la dirección equivocada más rápido. Kari's Law y las reglas de ubicación despachable de la FCC están en nuestra guía de llamadas de emergencia, y las obligaciones de 9-1-1 por VoIP en Canadá, en su sección sobre Canadá. Esta pieza profundiza en la capa de NG911 que está debajo.
Qué es NG911, en términos de ingeniería
La definición de la FCC, en 47 CFR § 9.28, enumera seis propiedades. NG911 es "an Internet Protocol-based system" (un sistema basado en el protocolo de internet) que garantiza la interoperabilidad, es seguro, emplea estándares de aceptación común, "enables emergency communications centers to receive, process, and analyze all types of 911 requests for emergency assistance" (permite a los centros de comunicaciones de emergencia recibir, procesar y analizar todo tipo de solicitudes de asistencia al 911), obtiene e integra información adicional útil, y permite compartir esa información entre los centros de comunicaciones de emergencia y los equipos de respuesta.1
La ESInet. El transporte es una Red IP de Servicios de Emergencia (Emergency Services IP Network): "an Internet Protocol (IP)-based network that is managed or operated by a 911 Authority or its agents or vendors and that is used for emergency services communications" (una red basada en IP administrada u operada por una autoridad de 911, sus agentes o proveedores, y usada para las comunicaciones de los servicios de emergencia).1 En la práctica es una red administrada que opera para la autoridad de 911 y a la que los proveedores de origen entregan el tráfico en los puntos de entrega que la autoridad designa.
Los servicios centrales. Sobre la ESInet están los Servicios Centrales de NG911 (NGCS) que, en palabras de la FCC, "collectively replace the caller location and routing functions of selective routers, ANI/ALI databases, and the MSAG in legacy 911 networks" (reemplazan en conjunto las funciones de ubicación y enrutamiento de los enrutadores selectivos, las bases de datos ANI/ALI y el MSAG de las redes 911 heredadas). Incluyen una Función de Validación de Ubicación, "a server that validates civic location information against a Geographic Information System (GIS) database" (un servidor que valida la ubicación cívica contra una base de datos de un Sistema de Información Geográfica), y una Función de Enrutamiento de Llamadas de Emergencia que "determines the appropriate destination PSAP by mapping the caller's validated location within the boundaries of emergency response zones" (determina el PSAP de destino adecuado al ubicar la posición validada de quien llama dentro de los límites de las zonas de respuesta a emergencias).5 La Fase 2 también permite que los puntos de atención "use policy routing functions to dynamically reroute 911 traffic to avoid network disruptions" (usen funciones de enrutamiento por políticas para redirigir dinámicamente el tráfico del 911 y evitar interrupciones de la red).2
El estándar. La arquitectura es el estándar i3 de NENA. El texto vigente es NENA-STA-010.3f-2021, que NENA describe como un "ANSI Approved Standard" que da "the detailed functional and interface specifications for a post-transition IP (Internet Protocol)-based multimedia telecommunications system, including the Core Services and legacy gateways" (las especificaciones funcionales y de interfaz detalladas de un sistema de telecomunicaciones multimedia basado en IP posterior a la transición, incluidos los Servicios Centrales y las pasarelas heredadas). La versión 3 trasladó las interacciones de datos entre elementos funcionales a una arquitectura REST/JSON y reformó la conexión de llamadas, entre otros cambios; NENA marca el estándar como "Currently Under Revision" (actualmente en revisión).7 Canadá usa la misma arquitectura: el CRTC aprobó "the adoption of the National Emergency Number Association (NENA) i3 architecture standard for NG9-1-1 in Canada" (la adopción del estándar de arquitectura i3 de NENA para NG9-1-1 en Canadá) en la Decisión de Telecomunicaciones 2015-531.26
Las pasarelas. i3 "provides for Legacy Network Gateways (LNGs) and other transitional network elements to ensure that TDM-based OSPs can originate 911 calls and that legacy PSAPs can receive them while the NG911 transition is ongoing" (prevé pasarelas de red heredadas y otros elementos de red de transición para que los proveedores TDM puedan originar llamadas al 911 y los PSAP heredados puedan recibirlas mientras dura la transición a NG911).2 La orden de 2026 de la FCC describe las "transitional NG911 networks" (redes NG911 de transición) resultantes, que "may retain selective routers, ANI/ALI, and other legacy elements as part of the call path" (pueden conservar enrutadores selectivos, ANI/ALI y otros elementos heredados en la ruta de la llamada).5
Ubicación por valor, ubicación por referencia
Para quien administra un sistema telefónico, la idea más útil de NG911 es que la ubicación pasa a ser parte de la llamada. Los componentes del IETF son antiguos y estables:
- PIDF-LO (RFC 4119) es "an object format for carrying geographical information on the Internet" (un formato de objeto para transportar información geográfica en internet) que extiende el Formato de Datos de Información de Presencia.8 La RFC 5139 reemplazó su formato de dirección cívica por uno más completo, que agrega elementos como edificio, unidad y sala a los campos existentes de piso y número de casa.9
- El transporte de ubicación en SIP (RFC 6442) define los campos de encabezado
Geolocation,Geolocation-RoutingyGeolocation-Error. El objeto de ubicación "may appear in a MIME body attached to the SIP request, or it may be a remote resource in the network" (puede aparecer en un cuerpo MIME adjunto a la solicitud SIP, o ser un recurso remoto en la red).10 - HELD (RFC 5985) es el protocolo que usa un dispositivo o servidor para obtener la ubicación "from a server within an access network" (de un servidor dentro de una red de acceso), "in two forms: by value and by reference" (de dos formas: por valor y por referencia).11 La RFC 6753 describe cómo un destinatario que tiene una referencia la resuelve por HTTPS para obtener el PIDF-LO.31
- LoST (RFC 5222) asigna "service identifiers and geodetic or civic location information to service contact URIs" (identificadores de servicio e información de ubicación geodésica o cívica a URI de contacto del servicio) y "can be used to determine the location-appropriate Public Safety Answering Point" (puede usarse para determinar el punto de atención de seguridad pública adecuado a la ubicación).12 El identificador de servicio para llamadas de emergencia es
urn:service:sos, que "reaches a public safety answering point (PSAP), which in turn dispatches aid appropriate to the emergency" (llega a un punto de atención de seguridad pública, que a su vez despacha la ayuda adecuada a la emergencia).13
Las reglas de la FCC usan el mismo vocabulario: un Servidor de Información de Ubicación es "a functional element that provides locations of endpoints" (un elemento funcional que proporciona las ubicaciones de los puntos finales), que "can provide Location-by-Reference or Location-by-Value, and, if the latter, in geodetic or civic forms" (puede proporcionar ubicación por referencia o por valor y, en este último caso, en forma geodésica o cívica).1 Por valor significa que el documento PIDF-LO viaja dentro del INVITE. Por referencia significa que el INVITE lleva un URI, y el punto de atención obtiene la ubicación actual del servidor del proveedor cuando la necesita, lo que importa para un dispositivo que se mueve durante la llamada.
Un ejemplo simplificado de una llamada desde un teléfono de escritorio con su ubicación adjunta por valor, con el encabezado de la RFC 6442 y los elementos cívicos de la RFC 5139. Es ilustrativo, no una captura de ningún proveedor: las llamadas i3 reales llevan más encabezados y el perfil exacto lo fija la autoridad de 911.109
INVITE urn:service:sos SIP/2.0
To: <urn:service:sos>
From: <sip:[email protected]>;tag=9fxced76sl
Geolocation: <cid:[email protected]>
Geolocation-Routing: yes
Content-Type: multipart/mixed; boundary=boundary1
--boundary1
Content-Type: application/sdp
...
--boundary1
Content-Type: application/pidf+xml
Content-ID: <[email protected]>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
entity="pres:[email protected]">
<tuple id="ext214"><status><gp:geopriv>
<gp:location-info>
<ca:civicAddress>
<ca:country>US</ca:country><ca:A1>OH</ca:A1>
<ca:A3>Example City</ca:A3>
<ca:RD>Main</ca:RD><ca:STS>Street</ca:STS><ca:HNO>100</ca:HNO>
<ca:FLR>3</ca:FLR><ca:UNIT>310</ca:UNIT>
</ca:civicAddress>
</gp:location-info>
</gp:geopriv></status></tuple>
</presence>
--boundary1--
Lo que importa para una empresa son las líneas FLR y UNIT. Con el E911 heredado, el punto de atención recibe un número de teléfono y busca la dirección que se haya cargado en la base de datos ALI para ese número. Con NG911 en Fase 2, el piso y la oficina pueden viajar con la llamada, y la dirección cívica se verifica contra el GIS de la autoridad de 911: según el § 9.28, una dirección es válida solo si "can be located within the database uniquely, is suitable to provide an accurate route for an emergency call, and is adequate and specific enough to direct responders to the right location" (puede ubicarse de forma única en la base de datos, sirve para dar una ruta precisa a una llamada de emergencia y es suficientemente específica para dirigir a los equipos de respuesta al lugar correcto).1 Una dirección que el antiguo callejero aceptó durante años puede no pasar esa prueba, y esa es una buena razón para preguntar a su proveedor si las direcciones de servicio de usted han sido validadas.
La orden de 2024 de la FCC: quién debe entregar qué, y cuándo
La FCC adoptó su Informe y Orden sobre NG911 (FCC 24-78, PS Docket Nos. 21-479 y 18-64) el 18 de julio de 2024; se publicó en 89 FR 78066 el 24 de septiembre de 2024 y entró en vigor el 25 de noviembre de 2024.2 Las reglas son 47 CFR §§ 9.27 a 9.34. Su premisa es que la FCC fija las obligaciones de los proveedores mientras que las autoridades de 911 estatales y locales deciden cuándo están listas, y las reglas "preserve the authority of state, territorial, regional, Tribal, and local government to adopt alternative approaches" (preservan la autoridad de los gobiernos estatales, territoriales, regionales, tribales y locales para adoptar enfoques alternativos).2
A quién obliga. Las obligaciones recaen en los "originating service providers" (proveedores de servicio de origen): proveedores de línea fija, proveedores móviles (CMRS), proveedores de texto cubiertos, "interconnected Voice over Internet Protocol (VoIP) providers, including all entities subject to subpart D" (proveedores de VoIP interconectado, incluidas todas las entidades sujetas a la subparte D) y proveedores de retransmisión por internet que enrutan tráfico al 911.1 Una empresa que opera su propia PBX no está en esa lista. Su operador o su proveedor de VoIP alojado sí lo está, y por eso las preguntas al final de esta página van dirigidas a los proveedores.
| Fase | Lo que el proveedor debe hacer (47 CFR § 9.29) | De dónde viene la ubicación |
|---|---|---|
| Fase 1 | Entregar todo el tráfico al 911 "in the IP-based SIP format requested by the 911 Authority" (en el formato SIP basado en IP que solicite la autoridad de 911) a los Puntos de Entrega NG911 designados, y completar las pruebas de conectividad.1 | Todavía se permiten medios heredados: el proveedor cubre la ubicación y el enrutamiento "using ALI/ANI databases, selective routers, or other means at Phase 1" (mediante bases de datos ALI/ANI, enrutadores selectivos u otros medios en la Fase 1).1 |
| Fase 2 | Entregar el tráfico al 911 en SIP "that complies with NG911 commonly accepted standards identified by the 911 Authority" (que cumpla los estándares de aceptación común de NG911 que identifique la autoridad de 911), con la ubicación incorporada como PIDF-LO "or the functional equivalent" (o su equivalente funcional); usar un LIS "for the verification of its customer location information and records" (para verificar la información y los registros de ubicación de sus clientes); completar las pruebas.1 | "using LIS functionalities or other equivalent means at Phase 2" (mediante funciones de LIS u otros medios equivalentes en la Fase 2).1 |
Deslice la tabla hacia los lados para ver todas las columnas.
| Tipo de proveedor (47 CFR § 9.30) | Plazo de la Fase 1 | Plazo de la Fase 2 |
|---|---|---|
| Línea fija no rural, operadores móviles de alcance nacional, proveedores de texto cubiertos, VoIP interconectado | 6 meses después de una solicitud válida de Fase 1 | 6 meses después de una solicitud válida de Fase 2 (o, si esa solicitud llega antes, 6 meses después del cumplimiento de la Fase 1 o de su plazo, lo que ocurra primero) |
| Operadores locales rurales históricos, operadores móviles sin alcance nacional, proveedores de retransmisión por internet | 12 meses después de una solicitud válida de Fase 1 | 12 meses, con la misma regla |
Deslice la tabla hacia los lados para ver todas las columnas.
Todo proveedor de VoIP interconectado, por pequeño que sea, está en el grupo de seis meses.1 A la FCC no la convenció que los proveedores de VoIP fueran a tener dificultades con la ubicación de la Fase 2: "interconnected VoIP providers already use a LIS functional element to transmit location information to 911 Authorities, subject to the NENA i2 standard" (los proveedores de VoIP interconectado ya usan un elemento funcional LIS para transmitir información de ubicación a las autoridades de 911, conforme al estándar NENA i2).2
Qué hace válida una solicitud. La autoridad de 911 debe certificar que su infraestructura receptora está instalada y funcionando, que sus proveedores se comprometen a terminar las pruebas a tiempo y que está autorizada para pedirlo; debe indicar sus puntos de entrega y notificar al proveedor "via a registry made available by the Commission" (mediante un registro que la Comisión pone a disposición) u otro aviso escrito aceptable. Para la Fase 2 también debe certificar la conexión con "a fully functioning Next Generation 911 Core Services network" (una red de Servicios Centrales de NG911 plenamente funcional).1 Un proveedor que considere prematura una solicitud tiene 60 días para presentar una petición a la FCC, mediante una declaración jurada de un director o funcionario.1
Quién paga. Los proveedores pagan para llevar su tráfico al 911 hasta los puntos de entrega en el formato requerido, "including the cost of IP conversion using a Legacy Network Gateway or the functional equivalent, if necessary" (incluido el costo de la conversión a IP mediante una pasarela de red heredada o su equivalente funcional, si es necesario); no son "responsible for the costs of furnishing, maintaining, or upgrading NG911 Delivery Points, ESInets, Next Generation 911 Core Services networks, or PSAPs" (responsables de los costos de suministrar, mantener o actualizar los puntos de entrega NG911, las ESInets, las redes de Servicios Centrales de NG911 ni los PSAP).1 Los proveedores y las autoridades pueden acordar otros términos, pero el proveedor debe notificarlo a la FCC en un plazo de 30 días.1
Las partes del registro y de las peticiones necesitaban la aprobación de la Oficina de Administración y Presupuesto federal (OMB). La FCC anunció esa aprobación, y que el cumplimiento ya era obligatorio, en un aviso vigente desde el 25 de marzo de 2025.3
En qué punto está realmente la transición en EE. UU.
Los datos del programa federal de 911 se detienen en 2021. El Programa Nacional de 911 (911.gov) describe NG911 como "a digital, internet protocol (IP)-based system that will replace the analog 911 infrastructure" (un sistema digital basado en el protocolo de internet que reemplazará la infraestructura analógica del 911) y remite a su Base de Datos de Perfiles de 911 para ver el avance de cada estado.20 El Informe Anual Nacional de 911 más reciente que enumera es el de datos de 2021.21 Ese informe dice que "2,287 PSAPs reported using an ESInet across 47 states" (2,287 PSAP informaron usar una ESInet en 47 estados), frente a 2,177 el año anterior; que 38 estados dijeron tener un plan estatal de NG911; y que 49 estados informaron 4,637 puntos de atención primarios.22 Usar una ESInet está lejos de tener i3 de extremo a extremo, y los datos son autoinformados.22
La propia lectura de la FCC en 2024. Al adoptar las reglas, la FCC escribió que "there are no fully enabled NG911 systems yet operating" (todavía no hay sistemas NG911 plenamente habilitados en funcionamiento), y señaló que un operador dijo haber logrado la preparación de extremo a extremo con dos jurisdicciones locales.2
El registro es ahora la mejor señal pública. En un aviso público de abril de 2026, la oficina de la FCC informó que su registro de solicitudes válidas de NG911 "posted 95 filings prior to November 1, 2025" (publicó 95 presentaciones antes del 1 de noviembre de 2025), que el personal estima en 72 solicitudes válidas de Fase 1 una vez descontadas las enmiendas y los retiros, y 81 presentaciones entre el 1 de noviembre de 2025 y el 31 de enero de 2026, estimadas en 58 solicitudes de Fase 1. En esa segunda ventana solo se habían publicado dos solicitudes de Fase 2.4 Las presentaciones están en el expediente 25-143 de la FCC, de modo que cualquiera puede comprobar si su estado o condado ya lo solicitó.4 El aviso también recuerda que las autoridades pueden notificar a los proveedores directamente, así que el registro no es una lista completa.4
Los primeros plazos ya se están atrasando, y los sistemas telefónicos de empresa son parte del motivo. El mismo aviso solicita comentarios sobre una petición de Verizon para extender al 30 de junio y al 31 de julio de 2026 sus plazos de la Fase 1 para el servicio de línea fija en Massachusetts y otras jurisdicciones. En el resumen de la oficina, Verizon afirma que su implementación de la Fase 1 de línea fija "was largely complete" (estaba en gran parte completa) a fines del primer trimestre de 2026, "but that additional time through mid-2026 will facilitate more seamless support for certain multi-line telephone system (MLTS) users' caller location functions" (pero que tiempo adicional hasta mediados de 2026 facilitará un soporte más fluido de las funciones de ubicación de quien llama para ciertos usuarios de sistemas telefónicos multilínea [MLTS]). Como alternativa, pide a la FCC que "waive or forbear from enforcing relevant Part 9 requirements for affected MLTS managers and operators" (renuncie a exigir o se abstenga de hacer cumplir los requisitos pertinentes de la Parte 9 a los administradores y operadores de MLTS afectados).4 No encontramos una resolución sobre la petición a la fecha de esta página. El detalle revelador: lo difícil para un gran operador no fue la ruta de voz, sino mantener funcionando la ubicación por extensión de los sistemas telefónicos de empresa.
En 2026 llegaron reglas de confiabilidad. En una Segunda Orden e Informe adoptada el 25 de junio de 2026 (FCC 26-39, vigente desde el 10 de agosto de 2026), la FCC dijo que había "seen a corresponding increase in major, multi-state 911 service outages" (visto un aumento correspondiente de interrupciones importantes del servicio 911 en varios estados) durante la transición, a menudo "in parts of transitional NG911 systems outside the scope of the 911 reliability framework adopted in 2013" (en partes de los sistemas NG911 de transición fuera del alcance del marco de confiabilidad del 911 adoptado en 2013). Puso a todos los proveedores de ESInet bajo sus reglas de confiabilidad del 911 y reemplazó la certificación anual de confiabilidad por una única; varios requisitos esperan un aviso posterior con la fecha de cumplimiento.5 Una propuesta complementaria exigiría pruebas de interoperabilidad interestatales entre varias partes y pregunta sobre las llamadas de video directas (Direct Video Calling).6
Canadá: una fecha nacional, y los centros de llamadas detrás
El enfoque de Canadá refleja el estadounidense. El CRTC regula a los proveedores, no a los centros de llamadas, y ha fijado fechas nacionales; los centros de llamadas, que son responsabilidad provincial, territorial y municipal, han tenido dificultades para seguir el ritmo.23
La historia. El marco es la Política Regulatoria de Telecomunicaciones 2017-182. Después de que la pandemia suspendiera sus plazos, la Decisión de Telecomunicaciones 2021-199 ordenó a los proveedores de red NG9-1-1, y a los proveedores de servicios de telecomunicaciones en redes técnicamente capaces, estar listos para la voz NG9-1-1 el 1 de marzo de 2022, y a los operadores históricos desmantelar los componentes de la antigua red 9-1-1 el 4 de marzo de 2025.25
La extensión de 2025. El 28 de febrero de 2025, la Decisión de Telecomunicaciones CRTC 2025-67 trasladó esa fecha de desmantelamiento al 31 de marzo de 2027. Los proveedores "have since made the necessary upgrades" (desde entonces han hecho las actualizaciones necesarias), dijo, pero "most provincial, territorial, and municipal emergency service organizations will not be able to make the necessary upgrades in time" (la mayoría de las organizaciones provinciales, territoriales y municipales de servicios de emergencia no podrán hacer las actualizaciones necesarias a tiempo).23 El informe del grupo de trabajo en que se basó decía que "only 3 of Canada's 242 PSAPs have launched NG9-1-1 services as of April 2024" (solo 3 de los 242 PSAP de Canadá habían lanzado servicios NG9-1-1 a abril de 2024) y pronosticaba que la gran mayoría no terminaría antes de fines de 2026; citaba la limitada capacidad de los proveedores para hacer pruebas y la escasez de experiencia técnica.23 La página del CRTC para consumidores lo plantea como una instrucción de "update their networks for NG9-1-1 voice services by March 31, 2027" (actualizar sus redes para los servicios de voz NG9-1-1 a más tardar el 31 de marzo de 2027).24
La decisión es directa sobre lo que ocurre después de esa fecha. Las pasarelas heredadas de PSAP "are not readily available in Canada" (no están fácilmente disponibles en Canadá), de modo que cualquier punto de atención que no haya migrado "will no longer be able to receive 9-1-1 calls" (ya no podrá recibir llamadas al 9-1-1); esos centros "must either complete their transition or make other arrangements" (deben completar su transición o tomar otras medidas), como "consolidation, co-location, or outsourcing of call taking functions to an NG9-1-1 PSAP" (consolidación, coubicación o subcontratación de las funciones de recepción de llamadas a un PSAP NG9-1-1).23 El CRTC no aceptó volver al 9-1-1 básico, y señaló que "cannot locate callers who are unable to verbally provide their location" (no puede ubicar a quienes llaman y no pueden indicar su ubicación de viva voz).23 Pidió a los jefes de servicios de emergencia un plan por provincia para el 28 de agosto de 2025, y al grupo de trabajo de la industria informes de avance semestrales hasta marzo de 2027.23
Quién paga mientras tanto. Hasta el desmantelamiento, los proveedores de origen pagan tanto la tarifa mayorista de E9-1-1 como la de NG9-1-1 (el "dual-rate model", o modelo de doble tarifa), lo que la decisión estima que les costará colectivamente "approximately $135-155 million" (aproximadamente de 135 a 155 millones de dólares) durante la extensión. Un operador dijo al CRTC que algunos proveedores "may need to add a new 9-1-1 charge to customer bills or increase prices" (quizá deban agregar un nuevo cargo de 9-1-1 a las facturas de los clientes o subir los precios).23
El VoIP local está incluido. Para esta decisión, los proveedores de servicios de telecomunicaciones incluyen a los que ofrecen "wireline and/or wireless local exchange telephone services, including local VoIP services" (servicios telefónicos de intercambio local por línea fija o inalámbrica, incluidos los servicios de VoIP local).23 La propia guía del CRTC sobre 9-1-1 por VoIP indica a los proveedores de VoIP local que consulten la Política Regulatoria de Telecomunicaciones 2017-182 "regarding upcoming next-generation 9-1-1 services" (sobre los próximos servicios 9-1-1 de próxima generación).27
Texto: texto en tiempo real, SMS y dos apuestas distintas
El texto es donde los dos países más se han separado.
Estados Unidos. El texto al 911 por SMS ya existe en 47 CFR § 9.10(q), que obliga a los "covered text providers" (proveedores de texto cubiertos): todos los operadores móviles más los servicios de mensajería de texto interconectados que llegan a "all or substantially all text-capable U.S. telephone numbers" (todos o casi todos los números telefónicos estadounidenses con capacidad de texto).16 Por separado, las reglas de texto en tiempo real (RTT) de la FCC (Parte 67) definen el RTT como texto "transmitted over Internet Protocol (IP) networks immediately as they are created, e.g., on a character-by-character basis" (transmitido por redes IP de inmediato a medida que se crea, por ejemplo, carácter por carácter), y exigen que los servicios y dispositivos cubiertos "transmit and receive RTT communications to and from any 911 public safety answering point (PSAP) in the United States" (transmitan y reciban comunicaciones RTT hacia y desde cualquier punto de atención de seguridad pública [PSAP] del 911 en Estados Unidos) y que lleven texto y voz al mismo tiempo en la misma llamada.15 El protocolo de referencia es la RFC 4103.1415 Los operadores móviles debían admitir el enrutamiento basado en ubicación del RTT al 911 en sus redes IP a más tardar el 13 de mayo de 2026.16
Canadá. El CRTC eligió el RTT y rechazó el SMS para NG9-1-1. En 2017 determinó que el texto al 9-1-1 por SMS, introducido como servicio provisional para canadienses sordos, con dificultades auditivas o del habla, "cannot be used without first placing a voice call" (no puede usarse sin hacer antes una llamada de voz), "is not IP-based" (no está basado en IP), "cannot be directly routed to the appropriate PSAP" (no puede enrutarse directamente al PSAP adecuado), "does not provide location information" (no proporciona información de ubicación) y se entrega con el mejor esfuerzo posible, y concluyó que "SMS is therefore not an appropriate solution for the provision of NG9-1-1 Text Messaging in Canada" (el SMS no es, por lo tanto, una solución apropiada para ofrecer mensajería de texto NG9-1-1 en Canadá).26 Los estándares para la devolución de llamada y la conexión del RTT no estaban listos en 2021, así que el CRTC no fijó entonces ningún plazo.25 Hoy su página para consumidores solo dice que "a deadline for providing NG9-1-1 real-time text messaging to the general public will be set at a later date" (se fijará más adelante un plazo para ofrecer al público general la mensajería de texto en tiempo real NG9-1-1).24
Qué significa para una empresa. La obligación de la Parte 67 en EE. UU. se aplica a los servicios que ya deben admitir RTT según otras partes de las reglas de la FCC,15 y no encontramos ninguna regla en ninguno de los dos países que obligue a una PBX de empresa a originar RTT al 911. Nuestra opinión: suponga que el texto de emergencia saldrá de los celulares personales del personal, no de los teléfonos de escritorio.
En los sistemas telefónicos de empresa la ubicación es lo más frágil
Un sistema telefónico multilínea tiene un número principal, muchas extensiones, a veces varios edificios y personal que se lleva una aplicación telefónica a casa. La ubicación siempre ha sido más débil ahí, y NG911 desplaza el punto débil en lugar de eliminarlo.
Las reglas de EE. UU. ya exigen ubicación desde el sistema. Desde 2021 para teléfonos fijos de escritorio y desde 2022 para dispositivos no fijos y fuera de las instalaciones, un MLTS debe transmitir la ubicación despachable al punto de atención: automática para los teléfonos fijos dentro de las instalaciones y, para los dispositivos fuera de ellas, automática "if technically feasible" (si es técnicamente factible); de lo contrario, una actualización manual o "the best available location that can be obtained from any available technology or combination of technologies at reasonable cost" (la mejor ubicación disponible que se pueda obtener de cualquier tecnología o combinación de tecnologías a un costo razonable).19
NG911 cambia la costura. En la Fase 2, el proveedor de origen debe entregar el PIDF-LO y usar un LIS para verificar los registros de ubicación de los clientes.1 En una PBX alojada, eso es problema de una sola empresa de principio a fin. En una PBX local conectada a una troncal SIP, la ubicación por extensión que conoce la PBX tiene que llegar al LIS del operador o insertarse en la llamada en una forma que el operador la deje pasar. La petición de Verizon descrita arriba es la primera señal pública de que en esa costura es donde la entrega por IP se complica.4 Nuestra opinión: la ubicación por referencia desde el LIS del proveedor es el diseño más robusto para los sistemas de empresa, porque el punto de atención puede obtener la ubicación actual en lugar de la que se cargó meses atrás; pero solo funciona si la empresa alimenta ese LIS, y no encontramos ninguna regla que diga cómo hacerlo.
La regla de VoIP no se ha reescrito para NG911. La regla del 911 para VoIP interconectado, 47 CFR § 9.11, se modificó en enero de 2026 pero sigue aplicándose "only to 911 calls placed by users whose dispatchable location is in a geographic area served by a Wireline E911 Network" (solo a las llamadas al 911 hechas por usuarios cuya ubicación despachable esté en un área geográfica atendida por una red E911 de línea fija), que por definición "includes a selective router" (incluye un enrutador selectivo), y sigue disponiendo que la ubicación esté "available ... from or through the appropriate automatic location information (ALI) database" (disponible ... desde o a través de la base de datos ALI correspondiente).1718 La subparte de NG911 existe en paralelo.1 Lo leemos como una superposición transitoria y no como un vacío de obligaciones, pero el texto literal de la regla de VoIP describe una red que se está retirando.
Canadá no tiene una ley de MLTS. El grupo de trabajo de la industria del CRTC identificó medidas al estilo estadounidense (marcación directa al 9-1-1, notificación en el lugar y "a dispatchable location requirement be established for MLTS 9-1-1 calls" [establecer un requisito de ubicación despachable para las llamadas al 9-1-1 desde MLTS]), pero señaló que "direct regulation of MLTS by the Commission is not feasible because Canada, unlike the United States, does not have federal or provincial legislation applicable to MLTS" (la regulación directa de los MLTS por parte de la Comisión no es factible porque Canadá, a diferencia de Estados Unidos, no tiene legislación federal ni provincial aplicable a los MLTS). El CRTC aprobó las mejores prácticas resultantes en la Decisión de Telecomunicaciones 2022-265.28 En 2023 abrió un procedimiento sobre "Enabling direct 9-1-1 and 9-8-8 calls from multi-line telephone systems" (habilitar las llamadas directas al 9-1-1 y al 9-8-8 desde sistemas telefónicos multilínea), y advirtió que "may impose obligations on providers of any telecommunications services that involve an MLTS" (podría imponer obligaciones a los proveedores de cualquier servicio de telecomunicaciones que involucre un MLTS) y "may also implement rules that would impact any organization that uses an MLTS" (también podría implementar reglas que afecten a cualquier organización que use un MLTS).29 La lista de decisiones sobre 9-1-1 del CRTC, en la copia más reciente que pudimos leer (agosto de 2025), no muestra ninguna decisión que cierre ese procedimiento.30 No pudimos revisar si la lista cambió desde entonces.
Dónde siguen las brechas: VoIP nómada y servicios de desvío
NG911 es una mejor tubería. Varias de las formas en que fallan las llamadas de empresa al 911 están antes de ella.
El VoIP nómada sigue dependiendo del usuario. Para el VoIP interconectado no fijo en EE. UU., la escalera de la regla es: ubicación despachable automática "if technically feasible" (si es técnicamente factible); si no, una Ubicación Registrada (Registered Location) que el usuario pueda actualizar, información de ubicación alternativa, o enrutar "the caller to a national emergency call center" (a quien llama a un centro nacional de llamadas de emergencia).17 La regla también permite enrutar las llamadas "first to a national emergency call center to ascertain the caller's location" (primero a un centro nacional de llamadas de emergencia para determinar la ubicación de quien llama) cuando el proveedor no puede obtener o confirmar esa ubicación.17 El aviso modelo para clientes de VoIP nómada en Canadá es más directo: "your 9-1-1 call is forwarded to a third-party service provider that will automatically or manually route your call" (su llamada al 9-1-1 se reenvía a un proveedor de servicios externo que la enrutará de forma automática o manual) y "you must immediately inform the emergency operator of your location" (usted debe informar de inmediato su ubicación al operador de emergencia).27 El CRTC también exige que los proveedores tengan un enrutamiento predeterminado de llamadas a un centro de llamadas externo "such as those used for nomadic voice over Internet Protocol (VoIP) calls" (como los que se usan para las llamadas de voz por protocolo de internet [VoIP] nómadas).25 Nada de esto cambia cuando el punto de atención se actualiza: una aplicación telefónica en un hotel sigue informando la última ubicación que el usuario registró, a menos que el proveedor pueda deducirla de la red.
Electricidad e internet. El aviso modelo del CRTC advierte que el 9-1-1 por VoIP depende "on Internet connectivity and power to function" (de la conexión a internet y de la electricidad para funcionar) y recomienda tener a mano "an alternative phone service (such as a cellular telephone)" (un servicio telefónico alternativo, como un teléfono celular).27 Una ESInet con conmutación automática por falla no sirve de nada para la oficina cuyo enrutador está en el mismo circuito que la cafetera.
Servicios de desvío. Muchas empresas pequeñas no tienen teléfonos de escritorio: el número de la empresa hace sonar los celulares del personal mediante desvío, un grupo de timbrado o una operadora automática. Una llamada al 911 sale entonces del propio celular, bajo las reglas de ubicación inalámbrica. Los operadores de alcance nacional en EE. UU. han debido implementar el enrutamiento basado en ubicación para las llamadas de voz inalámbricas al 911 en sus redes IP desde el 13 de noviembre de 2024, y los operadores sin alcance nacional desde el 13 de mayo de 2026.16 Nuestra opinión: para un equipo pequeño, una llamada al 911 desde un celular moderno suele estar mejor ubicada que una desde un teléfono de escritorio en una PBX mal mantenida. Las brechas están en otra parte:
- Aplicaciones telefónicas que hacen llamadas salientes. Si el personal usa una aplicación VoIP para hacer llamadas salientes "desde" el número de la empresa, una llamada al 911 hecha en esa aplicación es una llamada de VoIP nómada, con las limitaciones de la Ubicación Registrada descritas arriba, y no una llamada al 911 desde un celular. Pregunte cómo maneja la aplicación el 911. La respuesta más segura es que pasa la llamada al marcador nativo del teléfono.
- El número de devolución de llamada. Las definiciones de la FCC señalan que el ANI "identifies the calling party and may be used as the callback number" (identifica a quien llama y puede usarse como número de devolución de llamada).18 Si un sistema saliente presenta el número principal de la empresa en una llamada al 911, un despachador que devuelva la llamada llega a su menú telefónico o al buzón de voz, no a la persona que llamó. No encontramos ninguna regla que aborde esto para sistemas alojados pequeños, y NG911 transporta el número que se le dé. Compruebe qué número envía su sistema en una llamada al 911.
- Servicios solo de entrada. Un servicio que solo recibe llamadas y hace sonar celulares, como Auto Attendant, no puede hacer una llamada al 911 y debe decirlo con claridad. Su historia de llamadas de emergencia es la del operador celular, que es el sentido de nuestra página de llamadas de emergencia.
Qué debe revisar una pequeña empresa con sus proveedores
Esto requiere una lista de sus servicios telefónicos y unas cuantas respuestas por escrito, no un consultor.
- Haga una lista de todas las formas en que alguien de su empresa puede marcar 911 o 9-1-1: teléfonos de escritorio, líneas analógicas (incluidas las de alarma y de elevador), aplicaciones telefónicas, celulares y cualquier aplicación que haga llamadas. Junto a cada una, anote quién es el proveedor de origen. Ese proveedor carga con las obligaciones de NG911.1
- Pregunte a cada proveedor de VoIP o de línea fija si su autoridad de 911 le ha enviado una solicitud de Fase 1 o de Fase 2, y cuándo entregó o entregará. Las presentaciones de EE. UU. son públicas en el expediente 25-143 de la FCC, aunque no toda solicitud pasa por el registro.4
- Pregunte si las direcciones de servicio de usted se han validado contra el GIS de la autoridad de 911 (la Función de Validación de Ubicación), y no solo se aceptaron en la base de datos antigua, y si se guardan el piso y la oficina.1
- Para una PBX o un sistema alojado con varios pisos o sedes, pregunte cómo llega la ubicación por extensión al proveedor. ¿Es una ubicación por referencia desde el LIS del proveedor, un PIDF-LO que inserta la PBX o una base de datos heredada por número? ¿Quién la actualiza cuando alguien cambia de escritorio?419
- Para aplicaciones telefónicas y personal remoto, pregunte qué pasa en una llamada al 911 desde una ubicación no registrada. ¿Se le pide al usuario que la actualice, se deduce la ubicación de forma automática o la llamada va a un centro de llamadas nacional o externo?1727
- Revise el número de devolución de llamada que su sistema envía en una llamada al 911, y asegúrese de que un despachador que lo marque llegue a quien llamó o a alguien en el lugar, no a un menú.18
- En Canadá, pregunte a su proveedor qué significa para sus líneas el desmantelamiento del 31 de marzo de 2027, si cambiarán sus cargos de 9-1-1 y, para el VoIP nómada, cómo se enrutan las llamadas por su centro de llamadas externo.2327
- Pida por escrito el aviso de limitaciones del 911 o 9-1-1 de cada servicio de VoIP. Ambos países lo exigen para los servicios con limitaciones.1727
Nuestra opinión
Dónde la transición mejora claramente la seguridad. Una ubicación que forma parte de la llamada, verificada contra el GIS y capaz de llevar piso y oficina, es una mejora real frente a un número de teléfono buscado en una base de datos cargada a mano. El enrutamiento por políticas alrededor de un centro o enlace caído es una ganancia de resiliencia que el diseño del enrutador selectivo no podía ofrecer.25 El estándar único y la fecha nacional única de Canadá dejan sin ambigüedad el estado final.2326
Dónde creemos que se queda corta. Primero, el calendario de EE. UU. depende de la demanda, así que la mejora llega condado por condado, y los datos públicos para decirle a una empresa en qué punto está son antiguos o están enterrados en un expediente.214 Segundo, las nuevas redes traen nuevos modos de falla. La FCC dice expresamente que las interrupciones en varios estados aumentaron durante la transición.5 Tercero, los problemas más difíciles para las empresas no están en la red en absoluto: direcciones registradas desactualizadas, aplicaciones telefónicas fuera de la oficina, VoIP nómada que sigue terminando en un centro de llamadas que pregunta "¿dónde está?" y números de devolución de llamada que llegan a un menú. NG911 los transporta fielmente; no los corrige. Cuarto, en Canadá, una fecha firme de desmantelamiento de la red todavía no tiene detrás reglas vinculantes para MLTS ni una fecha para el RTT público.242830
La conclusión práctica no es emocionante: mantenga una lista exacta de dónde están sus teléfonos, haga que sus proveedores le digan por escrito cómo maneja cada uno el 911 y asegúrese de que el equipo sepa que un celular suele ser la forma más confiable de pedir ayuda. El trabajo en la red avanza sin usted; los datos de ubicación que su proveedor tiene de su empresa son algo que solo usted puede mantener exactos.
Lecturas recomendadas
Artículos de investigación más largos sobre este tema (en inglés), cada uno con sus fuentes y un PDF descargable.
Artículos sobre este tema
Fuentes
Cada afirmación sobre normas o precios en esta página enlaza a su fuente primaria, a menudo en inglés. Las normas y los precios cambian: verifique antes de confiar en una cifra.
- 47 CFR Part 9, Subpart J (§§ 9.27-9.34), Next Generation 911: definiciones (ESInet, LIS, LVF, NG911, proveedores de servicio de origen), requisitos de Fase 1 y Fase 2, plazos, solicitudes válidas, peticiones, puntos de entrega, responsabilidad de costos, acuerdos mutuos. Fuente: 89 FR 78128, modificado en 90 FR 13557. Edición vigente (leída mediante la API de eCFR, versión del 22 de octubre de 2026), consultado el 26 de octubre de 2026
https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-9/subpart-J - FCC, Facilitating Implementation of Next Generation 911 Services (NG911), Report and Order, FCC 24-78, PS Docket Nos. 21-479 and 18-64, 89 FR 78066 (24 de septiembre de 2024): fecha de adopción, fecha de entrada en vigor, fundamento de las Fases 1 y 2, i3 y pasarelas de red heredadas, conclusión sobre el LIS de VoIP, estado de la transición. Federal Register, consultado el 26 de octubre de 2026
https://www.federalregister.gov/documents/2024/09/24/2024-18603/facilitating-implementation-of-next-generation-911-services-ng911-location-based-routing-for - FCC, NG911 Report and Order: aprobación de la OMB y anuncio de la fecha de cumplimiento, 90 FR 13556 (25 de marzo de 2025). Federal Register, consultado el 26 de octubre de 2026
https://www.federalregister.gov/documents/2025/03/25/2025-04833/facilitating-implementation-of-next-generation-911-services-ng911-location-based-routing-for - FCC Public Safety and Homeland Security Bureau, DA 26-407, Bureau Seeks Comment on Verizon Petition for Waiver of NG911 Phase 1 Deadlines, PS Docket Nos. 21-479 and 25-143 (publicado el 24 de abril de 2026): número de presentaciones en el registro, tema de la ubicación de quien llama en MLTS. Consultado el 26 de octubre de 2026
https://docs.fcc.gov/public/attachments/DA-26-407A1.txt - FCC, Facilitating Implementation of NG911; Improving 911 Reliability, Second Report and Order, FCC 26-39 (adoptada el 25 de junio de 2026), 91 FR 42794 (10 de julio de 2026), vigente desde el 10 de agosto de 2026: Servicios Centrales de NG911, redes de transición, interrupciones en varios estados, proveedores de ESInet como proveedores de servicio 911 cubiertos, certificación única. Federal Register, consultado el 26 de octubre de 2026
https://www.federalregister.gov/documents/2026/07/10/2026-13998/facilitating-implementation-of-next-generation-911-services-ng911-improving-911-reliability - FCC, Facilitating Implementation of NG911; Improving 911 Reliability, Further Notice of Proposed Rulemaking, 91 FR 42699 (10 de julio de 2026): pruebas de interoperabilidad interestatal, Direct Video Calling. Federal Register, consultado el 26 de octubre de 2026
https://www.federalregister.gov/documents/2026/07/10/2026-13999/facilitating-implementation-of-next-generation-911-services-ng911-improving-911-reliability - NENA: The 9-1-1 Association, página de estándares i3: NENA-STA-010.3f-2021, NENA i3 Standard for Next Generation 9-1-1 (aprobado por ANSI; cambios de la versión 3; "Currently Under Revision"). Consultado el 26 de octubre de 2026
https://www.nena.org/page/i3_Stage3 - IETF RFC 4119, A Presence-based GEOPRIV Location Object Format (PIDF-LO), diciembre de 2005. Consultado el 26 de octubre de 2026
https://www.rfc-editor.org/rfc/rfc4119 - IETF RFC 5139, Revised Civic Location Format for PIDF-LO, febrero de 2008 (elementos cívicos como FLR, ROOM, UNIT, BLD). Consultado el 26 de octubre de 2026
https://www.rfc-editor.org/rfc/rfc5139 - IETF RFC 6442, Location Conveyance for the Session Initiation Protocol, diciembre de 2011 (campos de encabezado Geolocation; ubicación por valor o en la red). Consultado el 26 de octubre de 2026
https://www.rfc-editor.org/rfc/rfc6442 - IETF RFC 5985, HTTP-Enabled Location Delivery (HELD), septiembre de 2010 (ubicación por valor y por referencia). Consultado el 26 de octubre de 2026
https://www.rfc-editor.org/rfc/rfc5985 - IETF RFC 5222, LoST: A Location-to-Service Translation Protocol, agosto de 2008. Consultado el 26 de octubre de 2026
https://www.rfc-editor.org/rfc/rfc5222 - IETF RFC 5031, A Uniform Resource Name (URN) for Emergency and Other Well-Known Services (urn:service:sos). Consultado el 26 de octubre de 2026
https://www.rfc-editor.org/rfc/rfc5031 - IETF RFC 4103, RTP Payload for Text Conversation, junio de 2005 (texto en tiempo real, ITU-T T.140). Consultado el 26 de octubre de 2026
https://www.rfc-editor.org/rfc/rfc4103 - 47 CFR Part 67, Real-Time Text (§§ 67.1-67.3): definiciones, RTT a cualquier PSAP del 911, RFC 4103. Edición vigente (leída mediante la API de eCFR), consultado el 26 de octubre de 2026
https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-67 - 47 CFR § 9.10, 911 service (CMRS): (q) texto al 911 y proveedores de texto cubiertos; (s) plazos de enrutamiento basado en ubicación para voz y RTT. Edición vigente (leída mediante la API de eCFR), consultado el 26 de octubre de 2026
https://www.ecfr.gov/current/title-47/section-9.10 - 47 CFR § 9.11, E911 service for interconnected VoIP (alcance, opciones de ubicación no fija, centro nacional de llamadas de emergencia, notificación al cliente). Modificado en 91 FR 1403, 14 de enero de 2026. Edición vigente (leída mediante la API de eCFR), consultado el 26 de octubre de 2026
https://www.ecfr.gov/current/title-47/section-9.11 - 47 CFR § 9.3, Definitions (ANI como número de devolución de llamada, ubicación despachable, Registered Location, Wireline E911 Network). Edición vigente (leída mediante la API de eCFR), consultado el 26 de octubre de 2026
https://www.ecfr.gov/current/title-47/section-9.3 - 47 CFR § 9.16, Multi-line telephone systems: marcación directa, notificación y ubicación despachable. Edición vigente (leída mediante la API de eCFR), consultado el 26 de octubre de 2026
https://www.ecfr.gov/current/title-47/section-9.16 - National 911 Program (911.gov), Next Generation 911. Última actualización: 15 de mayo de 2025. Consultado el 26 de octubre de 2026
https://www.911.gov/issues/ng911/ - National 911 Program (911.gov), página del National 911 Annual Report (el más reciente: datos de 2021). Última actualización: 21 de febrero de 2023. Consultado el 26 de octubre de 2026
https://www.911.gov/projects/national-911-annual-report/ - National 911 Program y NASNA, National 911 Annual Report: 2021 Data (uso de ESInet, planes estatales de NG911, número de PSAP primarios). Consultado el 26 de octubre de 2026
https://www.911.gov/assets/2021-911-Profile-Database-Report_FINAL.pdf - Telecom Decision CRTC 2025-67, Various applicants – Updated timeline for full transition to Next-Generation 9-1-1 (Gatineau, 28 de febrero de 2025). Leído en una copia de Internet Archive (el sitio del CRTC bloquea el acceso automatizado), copia del 10 de marzo de 2026; leído el 26 de octubre de 2026
https://crtc.gc.ca/eng/archive/2025/2025-67.htm - CRTC, Next-generation 9-1-1 (página para consumidores). Fecha de modificación: 28 de febrero de 2025. Leído en una copia de Internet Archive (el sitio del CRTC bloquea el acceso automatizado), copia del 1 de octubre de 2026; leído el 26 de octubre de 2026
https://crtc.gc.ca/eng/phone/911/gen.htm - Telecom Decision CRTC 2021-199, Establishment of new deadlines for Canada's transition to next-generation 9-1-1 (Ottawa, 14 de junio de 2021). Leído en una copia de Internet Archive (el sitio del CRTC bloquea el acceso automatizado), copia del 9 de marzo de 2026; leído el 26 de octubre de 2026
https://crtc.gc.ca/eng/archive/2021/2021-199.htm - Telecom Regulatory Policy CRTC 2017-182, Next-generation 9-1-1 – Modernizing 9-1-1 networks to meet the public safety needs of Canadians (1 de junio de 2017): adopción de NENA i3, RTT elegido sobre SMS. Leído en una copia de Internet Archive (el sitio del CRTC bloquea el acceso automatizado), copia del 9 de marzo de 2026; leído el 26 de octubre de 2026
https://crtc.gc.ca/eng/archive/2017/2017-182.htm - CRTC, 9-1-1 Obligations of Local VoIP Service Providers in Canada (incluye el aviso modelo para clientes de VoIP nómada y fijo/no nativo). Leído en una copia de Internet Archive (el sitio del CRTC bloquea el acceso automatizado), copia del 9 de marzo de 2026; leído el 26 de octubre de 2026
https://crtc.gc.ca/eng/phone/911/voip.htm - Telecom Decision CRTC 2022-265, CISC ESWG consensus report ESRE0074b on multi-line telephone systems in E9-1-1 and NG9-1-1 (26 de septiembre de 2022). Leído en una copia de Internet Archive (el sitio del CRTC bloquea el acceso automatizado), copia del 13 de agosto de 2025; leído el 26 de octubre de 2026
https://crtc.gc.ca/eng/archive/2022/2022-265.htm - Telecom Notice of Consultation CRTC 2023-156, Call for comments – Enabling direct 9-1-1 and 9-8-8 calls from multi-line telephone systems (23 de mayo de 2023). Leído en una copia de Internet Archive (el sitio del CRTC bloquea el acceso automatizado), copia del 13 de junio de 2024; leído el 26 de octubre de 2026
https://crtc.gc.ca/eng/archive/2023/2023-156.htm - CRTC, Policies, decisions and orders for 9-1-1 services (lista de decisiones sobre 9-1-1). Leído en una copia de Internet Archive (el sitio del CRTC bloquea el acceso automatizado), copia del 3 de agosto de 2025 (no hay copia posterior); leído el 26 de octubre de 2026
https://crtc.gc.ca/eng/phone/911/pol.htm - IETF RFC 6753, A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD), octubre de 2012. Consultado el 26 de octubre de 2026
https://www.rfc-editor.org/rfc/rfc6753
