Un operador de sala de control puede seleccionar una tecla de megafonía del área de carga y hablar mediante auricular, manos libres o micrófono. Tras esa acción, el control de llamadas debe autorizar el destino, el equipo receptor debe aceptar el anuncio y la ruta de medios debe entregar audio a los altavoces correctos. Que un teléfono esté registrado no demuestra que esta ruta funcione.
Situar el teléfono en la arquitectura completa de megafonía
El teléfono de despacho es el terminal del operador. Una IP PBX, un servidor SIP o una plataforma de despacho gestiona el enrutamiento y los permisos; los altavoces o las pasarelas proporcionan la salida. Una ruta IP habitual incluye teléfono, plataforma de control de llamadas, grupo de megafonía y altavoces SIP. Para equipos de megafonía existentes, una pasarela SIP alimenta un amplificador y circuitos de altavoces analógicos.
El teléfono y los terminales SIP receptores suelen registrarse en la plataforma, pero los números de grupo son destinos lógicos, no dispositivos físicos. Una aplicación de despacho independiente puede añadir selección de zonas, vinculación de alarmas y registros. Son capacidades de plataforma o integración, no consecuencias automáticas de la compatibilidad SIP.
Elegir el método de conexión para cada destino
| Método | Aplicación y comprobaciones |
|---|---|
| Extensión SIP individual | Llamar a un altavoz para un área pequeña o una prueba de mantenimiento; confirmar respuesta automática y reproducción compatibles. |
| Grupo de megafonía del servidor | Un número selecciona varios terminales; verificar capacidad de sesiones simultáneas, miembros y fallos parciales. |
| Pasarela de megafonía SIP | Alimentar equipos PA existentes; adaptar nivel de línea, impedancia, cableado balanceado o no balanceado, puesta a tierra y funcionamiento del relé. |
| Multicast controlado por SIP | Una plataforma convierte una llamada en audio de grupo; verificar formato de terminal, dirección de grupo y reenvío de red. |
Un teléfono compatible con multicast puede transmitir directamente, pero muchos teléfonos solo llaman a una plataforma que realiza la distribución. La señalización SIP y el audio multicast son mecanismos distintos. Compruebe IGMP snooping, el consultor IGMP, los límites de VLAN y el enrutamiento multicast cuando proceda; no suponga que un flujo multicast atraviesa subredes o una WAN.
Defina las zonas según cobertura física y responsabilidad operativa. Compartir un switch no convierte dos altavoces en parte de la misma zona de seguridad. Registre la correspondencia entre cada número, ubicación, circuito de amplificador y terminal receptor.
Configurar cuentas, medios y acceso
Configure dirección del servidor, extensión, identidad de autenticación, secreto, puerto, transporte y códecs compatibles. Asigne a cada terminal un nombre de ubicación significativo. Configure el modo documentado de respuesta automática del receptor y las restricciones de fuentes autorizadas. El cumplimiento de SIP no garantiza respuesta automática, y un encabezado de alerta específico de un servidor puede no funcionar con otro terminal.
| Área de configuración | Elementos que verificar |
|---|---|
| Teléfono y servidor | Cuenta, plan de marcación, rutas, transporte, credenciales y rol de usuario |
| Terminal receptor | Respuesta automática, nivel de audio, miembros de grupo y formato de medios compatible |
| Pasarela y amplificador | Interfaz de audio, temporización del relé, disponibilidad del amplificador y selección de circuitos |
| Red y alimentación | VLAN, QoS, presupuesto PoE, puertos RTP, firewall, NAT y control multicast |
Utilice un códec compatible en ambos extremos, como G.711 A-law o μ-law cuando se especifique. Un códec de menor ancho de banda requiere compatibilidad en toda la ruta; la transcodificación de la plataforma consume recursos y puede añadir demora. Incluya sobrecarga de paquetes y flujos simultáneos al calcular el ancho de banda. RTP por sí mismo no garantiza la entrega puntual ni reserva capacidad de red.
Restrinja los números de emergencia y de todas las zonas por rol autenticado y destino. Una tecla programable solo es un acceso directo; no debe conceder permisos. Limite las fuentes de respuesta automática, proteja la administración y aplique de forma coherente la seguridad de señalización y medios compatible en teléfono, servidor y pasarela.
Asignar teclas de zona a un flujo operativo claro
Los siguientes números ilustran una configuración y no son valores predeterminados del producto. Confirme las teclas y la capacidad de plataforma disponibles para la consola de despacho Becke Telcom seleccionada.
| Elemento o tecla | Destino de ejemplo |
|---|---|
| Teléfono de despacho | Extensión 2001 |
| Producción / tecla DSS 1 | 6201 |
| Almacén / tecla DSS 2 | 6202 |
| Área de carga / tecla DSS 3 | 6203 |
| Tecla de emergencia | 6299, con autorización en el servidor |
Etiquete las teclas con nombres de áreas reconocibles. La marcación rápida inicia una llamada; pulsar para hablar puede exigir mantener y soltar una tecla, según la implementación. Confirme la secuencia, la indicación de conexión y la liberación antes de formar a los operadores. No suponga que una tecla programable proporciona control del turno de palabra.
Las suscripciones BLF o la integración de plataforma pueden mostrar actividad del destino cuando existe compatibilidad. Especifique qué significa cada indicador: registrado, ocupado o seleccionado no prueba una reproducción audible. Si no existe integración de estado, proporcione otra indicación definida de disponibilidad.
Verificar la secuencia de llamada y la disponibilidad del audio
El operador selecciona una zona; el teléfono envía un SIP INVITE a la plataforma.
La plataforma comprueba la autorización y el enrutamiento del llamante y establece las sesiones de terminales o la ruta de pasarela necesarias.
Los terminales compatibles responden según su configuración; el sistema establece la entrega RTP o multicast.
El operador espera la indicación definida de disponibilidad y habla. Confirme que amplificador y altavoces están preparados, no solo que finalizó la señalización.
El operador termina la llamada o libera el control PTT compatible; la plataforma libera sesiones, relés y recursos de zona.
La plataforma guarda registros de operador, destino, hora y resultado cuando el registro está configurado.
Pruebe las primeras y últimas palabras de los anuncios. La demora de establecimiento puede cortar el principio y una liberación prematura puede cortar el final. Defina tonos de inicio, demora previa y demora de liberación necesarios según mediciones del equipo. Después, compruebe el retorno previsto a espera, música de fondo o audio programado.
Explicitar la política de prioridad y conflictos
Decida si una segunda solicitud recibe ocupado, entra en cola, espera al hablante actual o interrumpe un anuncio de menor prioridad. Defina quién puede interrumpir qué zonas, cómo se transfiere el control y qué ven los operadores. Evite audio mezclado e interrupciones no autorizadas.
La prioridad de emergencia requiere comportamientos compatibles en plataforma, pasarela y receptor. El encabezado Priority de SIP no es una anulación universal de megafonía. La extensión Resource-Priority contempla precedencia autorizada de recursos en sistemas compatibles; no demuestra que un altavoz concreto pueda detener música de fondo o interrumpir de forma prioritaria otra emisión. Pruebe el mecanismo elegido en toda la ruta.
Una grabación o una llamada SIP contestada puede demostrar que hubo una sesión. Ninguna prueba la salida del amplificador, el funcionamiento del altavoz, la inteligibilidad o que las personas oyeran el mensaje. Utilice supervisión adecuada de terminales y amplificadores, pruebas de audio en campo y confirmación operativa cuando se requiera.
Poner en servicio la ruta del micrófono al altavoz
Llame a cada zona y verifique nombre mostrado, dispositivos activados, cobertura, volumen y liberación. Pruebe destinos individuales y de todas las zonas, operadores simultáneos, audio rutinario frente a emergencia, llamantes rechazados y retorno a reproducción normal. Incluya el ruido de fondo y las condiciones de micrófono reales de los operadores.
| Síntoma | Comprobaciones |
|---|---|
| Fallo de registro | Servidor, cuenta, credenciales, transporte, puerto y acceso de red |
| Zona inaccesible o incorrecta | Plan de marcación, mapa de grupos, rutas y autorización |
| Timbre sin reproducción | Modo de respuesta automática compatible y fuentes de confianza |
| Conexión sin audio | Códec, rutas RTP, firewall, NAT, entrada del amplificador y silencio |
| Altavoces ausentes o interrumpidos | Miembros de grupo, IGMP, consultor, VLAN, ancho de banda, pérdida de paquetes y alimentación |
| Zona que permanece ocupada | Liberación de sesión, comportamiento PTT, relé de pasarela y tiempo de espera del terminal |
| Fallo de anulación de emergencia | Política de roles y prioridad compatible en cada etapa |
Por último, pruebe la pérdida del servidor principal y la WAN. Un servidor de reserva o controlador local solo conserva la megafonía si terminales, rutas, medios, autenticación, pasarelas, LAN y alimentación permanecen disponibles en ese modo. Verifique llamadas activas y recuperación; consulte la arquitectura en despacho de emergencias multisede.
Preguntas frecuentes
¿Puede un teléfono llamar a un altavoz sin PBX?
Es posible si ambos terminales admiten llamadas entre pares compatibles. Compruebe direccionamiento, respuesta automática y seguridad. Los grupos centrales, permisos y conmutación de respaldo siguen necesitando una implementación adecuada.
¿Se necesita siempre un servidor de megafonía dedicado?
No. Una PBX compatible puede proporcionar llamadas y grupos básicos. Las zonas complejas, horarios, alarmas, supervisión y prioridad pueden requerir una plataforma o integración dedicada.
¿Puede un teléfono emitir a varios altavoces?
Sí, mediante un grupo de servidor o una solución multicast compatibles. Verifique capacidad de sesiones, compatibilidad de red y comportamiento cuando solo algunos altavoces aceptan el anuncio.
¿La compatibilidad SIP demuestra anulación de emergencia o entrega audible?
No. Verifique la interoperabilidad de prioridad y pruebe la salida física de audio por separado. La aceptación de llamadas y los registros no demuestran que el personal oyera la instrucción.
Referencias técnicas
RFC 3261 define la señalización SIP y el encabezado Priority; RFC 3550 define RTP y sus limitaciones de transporte; RFC 4412 define la prioridad autorizada de recursos de comunicación. El funcionamiento de las zonas de megafonía sigue siendo responsabilidad de la implementación y la puesta en servicio.
