P: ¿Cuál es uno de los riesgos de comunicación más graves en un centro de mando de emergencias?
R: No siempre se trata de una caída completa de la red. El videowall puede seguir funcionando, los conmutadores pueden permanecer en línea y los operadores continuar en sus puestos, pero la plataforma de despacho puede dejar de ser accesible, las funciones de despacho con un solo toque pueden dejar de responder, el directorio de contactos puede quedar indisponible y los flujos de llamadas que normalmente dependen del software pueden interrumpirse de repente.
Esto plantea de inmediato una pregunta práctica: si un operador necesita contactar con una sala de guardia en el sitio, emitir un aviso de emergencia a una zona concreta, comunicarse con usuarios de radio o llamar a un centro de mando de nivel superior, ¿debe la operación limitarse a esperar a que se recupere la plataforma principal?
Para un sistema de comunicaciones encargado de la respuesta a emergencias, la respuesta debería ser claramente no. La plataforma de mando y despacho puede fallar, pero la comunicación de voz local esencial no debería fallar con ella.
El valor de un teléfono SIP de megafonía en esta situación no está en sustituir un sistema completo de mando y despacho. Su función es conservar una interfaz fija de voz relativamente independiente y directa. Con una arquitectura adecuada, los operadores pueden seguir realizando llamadas punto a punto, utilizar líneas directas, iniciar llamadas de grupo o avisos de megafonía y acceder a canales de radio o telefonía externa aunque el software de despacho, los servidores de aplicaciones o las redes superiores estén temporalmente fuera de servicio.
Estos terminales suelen admitir conectividad SIP junto con manos libres, audio amplificado, teclas DSS, funciones de línea directa o interfaces de audio externas. En un centro de mando de emergencias, la cuestión clave no es cuántas funciones ofrece el teléfono, sino qué funciones de comunicación siguen siendo realmente utilizables después de que haya fallado la plataforma más compleja.
¿Qué capacidades de comunicación pueden perderse cuando falla la plataforma?
“Fallo de plataforma” no es una descripción técnica especialmente precisa. Un centro de mando de emergencias moderno puede incluir software de despacho, consolas con pantalla táctil, teléfonos SIP, una PBX IP, servidores de comunicaciones unificadas, SBC, servicios de megafonía, servicios de grabación y bases de datos. También puede conectarse a sistemas de radio, la PSTN, vídeo, alarmas y múltiples sitios remotos.
Dos incidencias pueden parecer al operador simplemente que “el sistema de despacho está caído”, aunque los puntos de fallo reales sean completamente distintos.
| Punto de fallo | Síntoma típico | Posible impacto en las comunicaciones locales |
|---|---|---|
| Software de despacho o interfaz web | Fallo de inicio de sesión, interfaz bloqueada o despacho de un toque no disponible | Los teléfonos fijos normalmente pueden seguir funcionando si el control de llamadas SIP continúa disponible |
| Plataforma central de aplicaciones | Fallo del directorio, la vinculación de eventos, el GIS o la base de datos | Depende de si el control básico de llamadas está separado de la capa de aplicaciones |
| WAN superior | Los servicios en la nube o una plataforma de mando de nivel superior dejan de ser accesibles | Las comunicaciones del sitio pueden continuar si existe control de llamadas local |
| Servidor de registro SIP | Los terminales pierden el registro y fallan las llamadas de extensión | Requiere registro de respaldo, un nodo SIP local u otro método alternativo |
| LAN local | Se pierde la conectividad IP entre terminales, servidores o pasarelas | Dos servidores SIP por sí solos no resuelven el problema; se necesita redundancia de red |
| Infraestructura eléctrica | Conmutadores, servidores y terminales quedan fuera de línea al mismo tiempo | Requiere alimentación mediante UPS, energía de respaldo o una vía de comunicación independiente |
Esta es la primera distinción importante al evaluar la resiliencia de las comunicaciones de emergencia: “no se puede operar la plataforma de despacho” no significa que “todas las comunicaciones estén indisponibles”.
Si el despacho por software, el registro SIP, el enrutamiento de marcación, el control de megafonía y las comunicaciones externas dependen de un único nodo central, una sola avería puede afectar a todos los servicios a la vez. Si el control básico de llamadas está correctamente separado de las aplicaciones de nivel superior, la pérdida de funciones avanzadas no impide necesariamente que los operadores utilicen teléfonos fijos para comunicaciones críticas.
¿Por qué un terminal SIP fijo puede seguir sirviendo como interfaz de comunicación local?
La principal ventaja de una consola de despacho por software es que puede reunir telefonía, megafonía, radio, vídeo, conferencias y alarmas en una sola interfaz de operación. Ese nivel de integración es valioso durante el funcionamiento normal, pero también significa que un fallo en la capa de aplicaciones puede eliminar de repente el punto de acceso habitual del operador a múltiples recursos de comunicación.
Un teléfono SIP fijo cumple otra función. No necesita gestionar todo el flujo de trabajo de un incidente. Su tarea principal es conservar la función más directa de todas: establecer comunicación de voz entre personas.
En condiciones normales, un operador puede utilizar el software de despacho para buscar contactos, crear conferencias o abrir una vista GIS. Si falla la estación de despacho, las teclas DSS fijas del teléfono aún pueden dar acceso directo al supervisor de guardia, la sala de control de incendios, la sala de equipos u otros puestos críticos.
En situaciones en las que cada segundo cuenta, la simplicidad puede convertirse por sí misma en una forma de fiabilidad.
Un terminal con un número reducido de teclas de línea directa claramente asignadas puede aportar más valor en una emergencia que una interfaz rica en funciones que dependa de bases de datos, servidores de aplicaciones y múltiples componentes de software.
Las funciones manos libres y de audio amplificado de un teléfono SIP de megafonía también pueden resultar útiles en salas de control con varios operadores. Durante una llamada urgente, el personal cercano puede escuchar información importante sin obligar al operador a permanecer con el auricular en la mano. En la implantación real siguen siendo necesarios controles sobre realimentación acústica, ruido ambiental, privacidad e interferencias entre puestos próximos.
Definir los dominios de fallo antes de diseñar la operación local de respaldo
Uno de los errores más comunes en el diseño de respaldo es suponer que añadir otro dispositivo crea automáticamente redundancia del sistema.
Por ejemplo, dos servidores SIP pueden parecer una arquitectura principal y de respaldo. Sin embargo, si ambas máquinas virtuales se ejecutan en el mismo host físico, se conectan por el mismo conmutador central, utilizan el mismo enlace ascendente y dependen de la misma UPS, siguen compartiendo varias condiciones de fallo importantes.
Un servidor de respaldo puede ayudar cuando falla el propio servidor principal, pero una avería del conmutador, del host de virtualización o de la alimentación eléctrica podría dejar ambos sistemas fuera de servicio al mismo tiempo.
Por tanto, la continuidad de las comunicaciones locales debe diseñarse en torno a niveles de fallo concretos.
Fallo de la capa de aplicaciones: El software de despacho no está disponible, pero las llamadas SIP siguen operativas.
Fallo de la capa de plataforma: Falla el nodo principal de aplicaciones y el control local de llamadas de respaldo mantiene las comunicaciones esenciales.
Fallo de WAN: La plataforma de nivel superior deja de ser accesible, mientras la telefonía local, la megafonía y la radio continúan funcionando.
Fallo de LAN: Se requiere conmutación redundante, enlaces ascendentes dobles u otro método de comunicación local.
Fallo eléctrico: Se necesitan sistemas UPS, alimentación de respaldo y, cuando corresponda, métodos de comunicación independientes.
El nivel de resiliencia necesario debe definirse durante el diseño del sistema. Una sala de guardia corporativa normal y un centro de mando de emergencias que atiende seguridad pública, energía, transporte o una gran instalación industrial no tienen por qué requerir el mismo nivel de continuidad.
Un principio útil es sencillo: la ruta de respaldo no debería compartir exactamente los mismos puntos únicos de fallo que la ruta principal.
¿Cómo puede construirse un sistema práctico de comunicación local de respaldo?
Que un teléfono SIP de megafonía siga siendo útil después de un fallo de plataforma no depende de una sola función. Depende del trabajo conjunto entre el control de llamadas local, el registro de respaldo, la numeración, el acceso a recursos de megafonía y radio, la arquitectura de red y la continuidad eléctrica.
Mantener el control básico de llamadas en el sitio
Si todo el registro de extensiones y el control de llamadas de un centro de mando de emergencias están alojados en un centro de datos remoto o en una plataforma en la nube, una caída de la WAN puede impedir que dos teléfonos SIP del mismo edificio se llamen utilizando sus números de extensión habituales.
En sitios críticos puede mantenerse localmente una PBX IP, un servidor SIP o un nodo de comunicaciones con capacidad de continuidad local. Durante el funcionamiento normal, el sitio puede seguir administrándose de forma centralizada. Si falla la conexión superior o la plataforma principal de aplicaciones, el nodo local continúa proporcionando la numeración y las funciones básicas de control de llamadas.
El sistema de respaldo no necesita reproducir todas las capacidades de la plataforma principal de mando. GIS, vinculación de vídeo, conferencias complejas, flujos de incidentes y acceso a datos históricos pueden degradarse temporalmente mientras la comunicación de voz crítica entre personas permanece disponible.
Las funciones pueden resumirse de forma sencilla: la plataforma principal ofrece la experiencia operativa completa, mientras el nodo local mantiene vivas las comunicaciones esenciales.
Solución relacionada: Sistema de despacho de telefonía IP para centros de mando y control
Proporcionar registro SIP principal y de respaldo
Los terminales con las capacidades necesarias pueden configurarse con un servidor SIP principal y otro de respaldo, o con otro mecanismo de doble registro o conmutación ante fallos. Si el nodo principal deja de ser accesible, el terminal puede pasar a un servicio de control de llamadas de respaldo y continuar estableciendo nuevas llamadas.
Los proveedores implementan este comportamiento de distintas formas. Algunos terminales mantienen dos cuentas simultáneamente, otros utilizan prioridades de servidor principal y secundario, mientras que otros dependen de DNS, clústeres o mecanismos de alta disponibilidad del lado del servidor.
La presencia de dos direcciones de servidor en una página de configuración no demuestra que la conmutación ante fallos funcione correctamente. Las pruebas deben determinar con qué rapidez detecta el terminal el fallo del nodo principal, cuánto tarda en volver a registrarse, qué ocurre con las llamadas activas, cuándo vuelven a estar disponibles las nuevas llamadas y si el terminal regresa al nodo principal después de la recuperación.
También es importante verificar si los servidores principal y de respaldo siguen compartiendo el mismo dominio de fallo físico. Si ambos dependen de un único conmutador central o de un mismo circuito eléctrico, su resiliencia real sigue siendo limitada.
Mantener familiares los números y las teclas durante un fallo
Incluso un sistema de respaldo técnicamente completo aporta un valor limitado si los operadores no pueden utilizarlo con rapidez.
Después de un fallo de la plataforma principal, pedir al personal que recuerde un nuevo prefijo de marcación, utilice otras extensiones o empiece a introducir direcciones IP manualmente puede generar errores adicionales justo en el peor momento.
Los destinos críticos, como el jefe del incidente, el supervisor de guardia, la sala de control de incendios, el control de megafonía, la pasarela de radio, la sala de equipos y otros puestos de guardia, pueden asignarse a números cortos fijos, teclas DSS o líneas directas.
El funcionamiento normal y el modo de respaldo deberían conservar la misma numeración y los mismos hábitos de uso siempre que sea posible. El sistema de fondo debe cambiar el enrutamiento real sin obligar al operador a aprender otro flujo de trabajo.
Algunos puestos de emergencia también pueden utilizar línea directa o marcación automática al descolgar para que al levantar el auricular se conecte inmediatamente con un destino predefinido. Estas funciones deben configurarse de acuerdo con las responsabilidades operativas y el riesgo de activación accidental, no aplicarse por igual a todos los terminales.
Conservar accesos alternativos a megafonía, radio y líneas externas
La respuesta a emergencias depende de algo más que llamadas telefónicas. Un responsable puede necesitar emitir de inmediato un aviso a una zona concreta, contactar con personal de campo mediante DMR, PDT, TETRA, PoC u otro sistema de radio y comunicarse con organizaciones externas a través de la red telefónica pública.
Si todos estos recursos solo pueden utilizarse desde la aplicación principal de despacho, un fallo de software puede eliminar varios canales de comunicación al mismo tiempo.
Un teléfono SIP de megafonía puede utilizar números predefinidos para acceder a estos recursos. Puede llamar a una pasarela SIP de megafonía para entrar en una zona de anuncios, conectarse a un canal de radio mediante una pasarela RoIP o utilizar una interfaz FXO, un troncal SIP u otra pasarela de voz para acceder a telefonía externa.
Teléfono SIP de megafonía
→ Control de llamadas SIP local
→ Pasarela de megafonía / Pasarela RoIP / Pasarela de voz externa
→ Altavoces del sitio / Sistema de radio / PSTN
Esta arquitectura permite a los operadores acceder a otros sistemas de comunicación desde un terminal de voz fijo incluso cuando la estación de despacho más compleja no está disponible.
Proteger también la red y la infraestructura eléctrica
Muchos sistemas de comunicaciones utilizan servidores redundantes pero siguen dependiendo de un único conmutador PoE en la capa de acceso. Si ese conmutador pierde alimentación, todos los teléfonos conectados pueden quedar fuera de línea a la vez y el doble registro SIP deja de aportar valor.
Según el nivel de resiliencia requerido, los terminales críticos pueden utilizar rutas de conmutación redundantes, el equipo de red central puede contar con fuentes de alimentación dobles o despliegue redundante, y los conmutadores PoE, servidores SIP locales, pasarelas de megafonía y pasarelas RoIP pueden incluirse en la carga respaldada por UPS.
Los despliegues con varias salas o edificios también deberían revisar conmutadores de agregación, enlaces de fibra y rutas ascendentes para detectar puntos únicos de fallo adicionales.
El diseño de la UPS no debería basarse únicamente en una etiqueta como “dos horas de respaldo”. La carga crítica real debe calcularse a partir del consumo PoE, los servidores, los terminales de voz y todas las pasarelas necesarias que deban seguir funcionando durante un corte eléctrico.
Los sitios que deben seguir operativos durante fallos graves de infraestructura también pueden necesitar radio, líneas directas analógicas, comunicaciones por satélite u otros métodos fuera del entorno IP principal, de modo que la última capa de emergencia no dependa de las mismas condiciones de red y alimentación.
¿Qué capacidades deben conservarse primero durante la degradación de la plataforma?
El diseño de respaldo suele pasar por alto otro punto importante: un sistema degradado no necesita conservar todas las funciones de la plataforma normal.
Un sistema de mando puede incluir GIS, videovigilancia, conferencias, reproducción de grabaciones, mensajería, vinculación de alarmas y directorios de contactos. Reproducir todas estas funciones en un entorno de respaldo puede hacer que la plataforma alternativa sea cada vez más compleja y dependa de muchos de los mismos servicios que el sistema principal.
Un enfoque más práctico consiste en definir la capacidad mínima de comunicaciones aceptable durante una emergencia.
Las prioridades más altas suelen ser las llamadas punto a punto entre funciones críticas, las líneas directas fijas, el acceso a megafonía de emergencia, el acceso a radio y las llamadas externas esenciales. Que la grabación, las conferencias, el vídeo o el GIS también deban mantenerse dependerá del nivel operativo y de los requisitos del proyecto.
En la práctica, se trata de una forma controlada de degradación de las comunicaciones.
Durante el funcionamiento normal, el personal puede utilizar el entorno completo de despacho convergente. Si falla una parte de la plataforma, el sistema pasa a un modo de operación más sencillo pero más estable. Solo ante fallos más graves de red o alimentación, la comunicación se desplaza aún más hacia la radio u otras rutas de respaldo independientes.
En comunicaciones de emergencia, la pérdida temporal de funciones avanzadas es manejable; perder la capacidad de transmitir instrucciones esenciales no lo es.
¿Por qué “Registrado” y “En línea” no demuestran que el servicio funcione realmente?
Durante las pruebas de aceptación de un sistema de emergencia, a menudo se da demasiada importancia al estado del terminal.
Que la pantalla de un teléfono SIP de megafonía esté encendida solo demuestra que el dispositivo tiene alimentación. Un icono de red indica que existe cierto nivel de conectividad. El estado “Registrado” significa que el terminal ha completado el registro con un servidor registrador SIP. Ninguno de estos estados demuestra por sí solo que una llamada de extremo a extremo pueda completarse realmente.
El dispositivo tiene alimentación
≠ La LAN funciona completamente
≠ El servicio SIP funciona completamente
≠ El plan de marcación es correcto
≠ La ruta de medios RTP es alcanzable
≠ El terminal remoto puede completar una llamada normal
El problema habitual de “registrado pero sin audio” lo demuestra claramente. La señalización SIP puede completarse correctamente mientras RTP falla por problemas de enrutamiento, NAT, reglas de cortafuegos, negociación de códecs o una pasarela de medios.
Las llamadas que implican megafonía o radio requieren verificar además que la pasarela SIP, la pasarela RoIP o el propio servicio de megafonía sigan operativos.
Por tanto, las comunicaciones de emergencia deben validarse con servicios reales: realizar una llamada y confirmar audio bidireccional; entrar en una zona real de megafonía y comprobar que los altavoces de campo reproducen el aviso; conectarse a un canal de radio y confirmar comunicación bidireccional entre la sala de control y las radios de campo. “Registrado” es solo un estado de señalización. Lo que debe aceptarse es el resultado operativo real.
¿Cómo deben saber los operadores qué sigue funcionando después de un fallo?
Los ingenieros de comunicaciones pueden entender la relación entre servidores principales, servidores de respaldo, estados de registro y enrutamiento de red, pero la persona que ocupa el puesto de despacho durante una emergencia no tiene por qué ser un ingeniero de comunicaciones.
Si un fallo del sistema principal solo cambia un pequeño icono de estado de verde a gris, el operador puede no darse cuenta de que el terminal ha entrado en un modo de respaldo.
Los fallos de plataforma rara vez son tan simples como “todo funciona” o “todo está caído”. Algunas funciones pueden seguir disponibles mientras otras han fallado. Sin una indicación clara, los operadores se ven obligados a descubrir el estado del sistema por ensayo y error.
Cuando las capacidades del terminal lo permitan, los puestos críticos pueden mostrar el estado de registro principal y de respaldo, el estado de red o la disponibilidad de líneas directas esenciales. Las teclas DSS deberían priorizar destinos importantes durante una emergencia, en lugar de maximizar simplemente el número de contactos almacenados.
Una pantalla táctil con decenas de contactos dinámicos e iconos sofisticados puede quedar inutilizable cuando falla su base de datos de fondo. Un pequeño número de teclas fijas etiquetadas “Supervisor de guardia”, “Control de incendios”, “Megafonía”, “Radio” y “Línea externa” puede ofrecer un resultado mucho más predecible durante una situación degradada.
Desde el punto de vista operativo, la resiliencia tiene una prueba muy sencilla: después de que cambie el estado de la plataforma, los operadores no deberían tener que comprender primero el fallo para poder realizar la siguiente llamada crítica.
¿Por qué las pruebas de aceptación deben provocar fallos de forma intencionada?
Muchos proyectos realizan pruebas extensas de operación normal antes de la entrega: las llamadas conectan, la megafonía funciona, las grabaciones pueden reproducirse y el software de despacho es accesible. Estas pruebas demuestran que el sistema funciona en condiciones normales, pero no demuestran que el respaldo funcionará cuando sea necesario.
La continuidad de las comunicaciones locales debe validarse provocando fallos de manera intencionada.
Puede detenerse la plataforma principal de despacho para comprobar si los terminales fijos aún alcanzan los puestos críticos. Puede desconectarse la WAN superior para verificar que los números de extensión locales siguen siendo utilizables. El servidor SIP principal puede apagarse para medir cuánto tardan los terminales en detectar el fallo y pasar al nodo de respaldo. También pueden desconectarse rutas de red seleccionadas para confirmar que la redundancia toma realmente el relevo.
Si el proyecto incluye una UPS, también debería simularse un fallo de la red eléctrica para medir el tiempo real de funcionamiento de conmutadores PoE, servidores SIP, pasarelas y terminales críticos.
Un ejercicio práctico de fallos puede incluir los siguientes pasos:
Registrar el estado normal de los terminales, servidores y pasarelas críticos.
Detener intencionadamente la plataforma principal o el nodo SIP principal.
Confirmar que los terminales entran en el estado de respaldo esperado.
Llamar a puestos de operador críticos y líneas directas fijas.
Verificar audio bidireccional real, no solo el estado de registro.
Probar el punto de entrada de megafonía de respaldo.
Verificar la radio y las rutas externas de llamada necesarias.
Restaurar el sistema principal y observar el proceso de retorno.
Revisar alarmas, registros y la cronología del fallo.
Documentar cualquier paso que todavía requiera intervención manual.
El retorno al sistema principal después de su recuperación es igualmente importante. Algunos problemas no aparecen cuando el tráfico pasa al sistema de respaldo, sino únicamente cuando vuelve el nodo principal: pueden producirse registros duplicados, enrutamiento incorrecto o terminales que no regresan al nodo principal.
¿Qué define unas comunicaciones de emergencia fiables?
Ninguna plataforma de mando y despacho puede garantizar que su software, servidores, redes e infraestructura eléctrica nunca fallen. El verdadero objetivo del diseño de comunicaciones de emergencia no es eliminar todas las averías posibles, sino asegurar que siga disponible un nivel adecuado de capacidad de comunicación después de que se produzca un fallo.
Un teléfono SIP de megafonía desempeña una función básica pero importante en esta arquitectura: conserva la capacidad de una persona para iniciar directamente una comunicación de voz sin depender por completo de una interfaz de software compleja.
Durante el funcionamiento normal puede actuar como terminal SIP dentro del entorno unificado de despacho. Si falla la plataforma principal, puede seguir alcanzando puestos críticos mediante control de llamadas local, registro de respaldo y números fijos. Combinado con pasarelas de megafonía, pasarelas RoIP y pasarelas de voz externas, la misma interfaz básica de voz puede proporcionar acceso a la megafonía del sitio, las redes de radio y la PSTN.
La arquitectura puede soportar así varios niveles de operación degradada:
Operación normal: la plataforma unificada proporciona despacho centralizado
→ Fallo de software: los terminales SIP fijos conservan las llamadas básicas
→ Fallo de WAN: el control local de llamadas mantiene las comunicaciones del sitio
→ Fallo de una única ruta de voz: la megafonía, la radio o las líneas externas ofrecen rutas alternativas
→ Fallo grave de infraestructura: métodos independientes de comunicación de emergencia proporcionan el último respaldo
Este enfoque no exige que todas las funciones avanzadas permanezcan disponibles en todas las condiciones de fallo. El GIS puede quedar temporalmente indisponible, la recuperación de vídeo puede detenerse y las conferencias complejas pueden degradarse. Lo que debe permanecer es la capacidad más fundamental de respuesta a emergencias:
alguien puede realizar la llamada, alguien puede escucharla, la información crítica puede transmitirse y las instrucciones esenciales siguen llegando a las personas que las necesitan.
Preguntas frecuentes
¿Debe continuar la grabación durante la operación local de respaldo?
Depende de los requisitos operativos y de cumplimiento. La seguridad pública, la energía, el transporte y algunos grandes entornos industriales de emergencia pueden exigir que las comunicaciones de voz críticas sigan grabándose. Si la grabación es obligatoria, el diseño debe verificar si los medios continúan llegando a un servicio de grabación disponible durante el respaldo o si se requiere una capacidad de grabación local independiente.
¿Necesita cada centro de mando de sucursal su propio control de llamadas local?
No necesariamente. La decisión depende de la importancia del sitio, la fiabilidad de la WAN, el número de terminales y la interrupción de servicio aceptable. El control local de llamadas aporta más valor en sitios que deben seguir operando de forma independiente cuando la red superior no está disponible. Las sucursales pequeñas pueden estar suficientemente cubiertas por otros diseños centralizados de alta disponibilidad.
¿Los servidores SIP principal y de respaldo deben ser del mismo proveedor?
No es un requisito absoluto. Sin embargo, un despliegue multiproveedor aumenta las pruebas de interoperabilidad necesarias para el registro SIP, el enrutamiento de marcación, los códigos de función, los estados de suscripción y el comportamiento de conmutación ante fallos. “Ambos admiten SIP” no es prueba suficiente de que una redundancia sin interrupciones funcione con los terminales y servicios reales.
¿Cuándo debe mantenerse un método de comunicación independiente fuera del sistema IP?
Si los requisitos de continuidad incluyen fallos de la LAN central, cortes eléctricos prolongados, grandes desastres o interrupciones amplias de redes públicas, deberían considerarse la radio, líneas directas analógicas, comunicaciones por satélite u otro método con un dominio de fallo diferente. El diseño final debe reflejar el nivel de riesgo del sitio, su entorno operativo y los requisitos aplicables del proyecto.
Becke Telcom proporciona teléfonos SIP de megafonía, sistemas de despacho de telefonía IP, integración RoIP, megafonía IP y distintas pasarelas de voz para centros de mando de emergencias, instalaciones industriales e infraestructuras críticas. Estos componentes pueden utilizarse para construir una arquitectura de comunicaciones que combine el despacho centralizado normal con la operación local de respaldo, de acuerdo con los puestos críticos del sitio, la red existente, los escenarios de fallo y las rutas de respaldo necesarias.
