Monitor e Intercom

Son dos funcionalidades de audio sobre los DVR (N9M/Aibox) que se piden desde el frontend:

• Monitor: escuchar el micrófono/entrada de audio del vehículo. Es unidireccional (Device → Usuario), como un "walkie" en modo escucha.
• Intercom: hablar con el vehículo, en las dos direcciones (Device ↔ Usuario), como una llamada telefónica.

Cómo se ve en el frontend

En la barra de video en vivo aparecen los íconos de auriculares (Monitor) y teléfono (Intercom):

Al iniciar cualquiera de los dos se muestra una barra de llamada con el dominio del vehículo, un cronómetro, el selector de canal y el botón de colgar:

Cambiar de canal desde ese selector corta automáticamente la sesión del canal anterior antes de pedir la del nuevo, para no dejar tareas de audio huérfanas corriendo en el dispositivo.

Proyectos involucrados

Proyecto	Rol
dashboard-k2	Frontend. AudioPlayer.vue (Monitor) e IntercomPlayer.vue (Intercom): piden la sesión, abren el WebSocket de audio y reproducen/capturan con Web Audio API.
apis (plataforma)	Expone POST /monitor, /monitor/stop, /intercom, /intercom/stop. Publica el pedido a Pub/Sub, sin persistir nada propio (no hay equivalente D2S/Java para audio).
user-request-handler	Cloud Function disparada por el Pub/Sub. Publica a Redis los canales hur_monitor_request / hur_intercom_request (pedido) y hur_monitor_control (stop, compartido por los dos).
n9m-center	Suscripto a esos canales de Redis. Le manda al DVR los comandos REQUESTTALK/CONTROLTALK del protocolo N9M, y guarda el pedido pendiente en Redis para poder correlacionar la respuesta async del DVR. Incluye un timeout de seguridad (10 min) que frena la sesión sola si nadie mandó el stop.
n9m-signal-processor	Recibe la respuesta del DVR (reenviada por n9m-center) y notifica el estado (pending / ready / failed) publicando a Redis.
sockets-communication	Reenvía esa notificación de Redis al frontend por Socket.IO (evento monitorAudio, a la room del usuario).
n9m-media-go	El media server real: el DVR se conecta ahí (puerto N9M) para mandar/recibir el audio. Decodifica G.711 A-law → PCM16 para que el browser escuche, y codifica el micrófono del browser a A-law para mandárselo al DVR. Expone el WebSocket wss://.../live/intercom?deviceid=<serie> que usa el frontend.

Flujo de información

Monitor (solo escuchar)

Este diagrama es del protocolo N9M del fabricante (Streamax); llevado a nuestros proyectos:

1. El frontend pide POST /monitor → Pub/Sub → user-request-handler publica hur_monitor_request.
2. n9m-center recibe ese mensaje y le manda al DVR el comando REQUESTTALK (CSRC: MONITOR).
3. El DVR responde, n9m-center reenvía esa respuesta hacia la nube (vía n9m-signal-processor), que publica el estado.
4. El DVR abre una conexión aparte contra n9m-media-go y arranca a mandar su audio.
5. n9m-signal-processor, al ver que la sesión de media efectivamente arrancó, publica status: "ready" con la URL del WebSocket (wss://.../live/intercom?deviceid=...).
6. El frontend recibe ese estado por Socket.IO y recién ahí abre el WebSocket para escuchar.
7. n9m-media-go decodifica el audio (G.711 A-law → PCM16) y se lo reenvía al browser en tiempo real.

Intercom (ida y vuelta)

Mismo esquema que Monitor (mismos proyectos, mismo canal de Redis de stop), con dos diferencias:

• El comando al DVR usa CSRC: INTERCOM en vez de MONITOR (mismo REQUESTTALK).
• El WebSocket es full-duplex: además de recibir audio del DVR, el frontend manda el audio de su propio micrófono por el mismo socket. n9m-media-go lo codifica a A-law y se lo reenvía al DVR, envuelto en el mismo formato de frame que usa el propio dispositivo para mandar audio.
• Al conectar el WebSocket, antes de que se escuche cualquier voz, n9m-media-go le manda al dispositivo un tono de "llamada entrante" (dual-tono telefónico, ~2.8s), y uno de "fin de llamada" al colgar — para que quien esté cerca del vehículo se dé cuenta de que están intentando hablarle, igual que en una llamada real.

Detalles técnicos relevantes

• Protocolo: MODULE: MEDIASTREAMMODEL, OPERATION: REQUESTTALK (iniciar) / CONTROLTALK (frenar), documentado en los PDFs N9M Protocol_ Monitoring e N9M Protocol_ Intercom de Streamax.
• Codec de audio: G.711 A-law, 8kHz, mono, frames de 320 bytes (AUDIOFRAMELEN, negociado en el REQUESTTALK).
• Transporte del audio hacia/desde el DVR: el envelope binario N9M (StreamaxFrame), documentado en el PDF Streamax Audio&Video Frame Definition. Los frames de audio que arma n9m-media-go para mandarle al DVR llevan 3 extensiones (Virtual time info, Audio Info, Encoding extension info) — se confirmó comparando bit a bit una captura de red real de una llamada de intercom funcionando (vía la API de otro proveedor que usa el mismo protocolo) contra lo que mandábamos nosotros.
• PayloadType: Intercom (5) en las dos direcciones (dispositivo→servidor y servidor→dispositivo), no un tipo distinto por dirección.
• El cliente web (dashboard-k2) manda su propio micrófono como PCM16 binario crudo (no A-law), así que n9m-media-go hace el encode a A-law y el chunking a frames de 320 muestras del lado del servidor.