Portal Stalker y STBs MAG: la capa de distribución que decide si el cliente ve algo

La capa que el cliente sí ve

En posts anteriores bajamos hasta la captación (TVHeadend, tarjetas TBS, muxes DVB-S2/DVB-T), la transcodificación (perfiles ABR en Flussonic), y el monitoreo de todo lo anterior en producción. Todo eso pasa detrás de la pantalla del cliente. Lo único que el cliente final ve —literalmente, encendiendo su televisor— es el portal: la lista de canales, la guía, la barra de categorías, el mensaje de error si algo falla. Ese portal, en la mayoría de las plataformas IPTV serias que corren sobre STBs dedicados, es Stalker (el middleware que Infomir desarrolló originalmente para sus propios decodificadores MAG, hoy comercializado también como Ministra TV Platform).

Es tentador tratar el portal como el paso final y trivial —"ya está todo transcodificado, solo falta mostrarlo"—. En la práctica es donde se concentran los errores más caros de diagnosticar, porque son los que el cliente reporta primero y los que menos se parecen a un problema de señal: un STB "no autorizado", un canal que aparece pero no reproduce, una guía que muestra la programación de ayer. Ninguno de esos síntomas apunta directamente a la causa.

Qué es realmente el portal: middleware, no reproductor

Stalker no decodifica ni transcodifica nada. Es una capa de autenticación, catálogo y orquestación entre el STB y los backends de streaming (en esta arquitectura, Flussonic). Tres piezas lo componen:

• Panel de administración — donde se cargan los canales (apuntando a las URLs que expone Flussonic), se arman los bouquets, se gestionan los dispositivos autorizados y se configuran reglas de acceso.
• Base de datos — dispositivos, bouquets, sesiones activas, historial de reproducción si el catch-up está habilitado.
• API HTTP que habla el STB — el cliente Stalker embebido en el firmware del MAG hace un handshake al portal, recibe la lista de canales autorizada para ese dispositivo específico, y a partir de ahí pide cada stream directamente al backend que el portal le indicó.

La distinción importa porque cuando algo falla, el primer diagnóstico correcto es separar "¿es un problema del portal (autorización, catálogo) o del backend (la señal en sí)?" — son sistemas distintos con logs distintos, y tratarlos como una sola caja negra alarga cualquier troubleshooting.

Autenticación: por MAC, no por usuario y contraseña

La diferencia más contraintuitiva frente a un servicio de streaming típico (Netflix, un OTT con login) es que el STB MAG no se autentica con credenciales de usuario. Se autentica con la dirección MAC de su interfaz de red, quemada de fábrica en el propio dispositivo. El flujo real:

1. El STB, al encender, resuelve la dirección del portal —normalmente vía un hostname preconfigurado en el firmware o entregado por DHCP (opción 60/vendor class, o una URL fija de portal)— y hace una petición HTTP incluyendo su MAC.
2. El portal busca esa MAC en su base de dispositivos. Si está registrada y activa, responde con un token de sesión y la lista de bouquets asignados a ese dispositivo.
3. Si la MAC no está registrada, el portal devuelve un estado de "no autorizado", y el STB muestra su pantalla de error nativa —no un mensaje del operador, sino la del firmware, lo cual confunde a cualquier cliente que no sepa que el problema está en la asignación, no en el equipo.

Esto tiene una consecuencia operativa directa: reemplazar un STB dañado no es "reinstalar la app con las mismas credenciales", es dar de baja la MAC vieja en el portal y dar de alta la nueva. Un proceso de reemplazo que no contempla ese paso dado dispositivo por dispositivo genera el ticket clásico de "cambié el equipo y ahora no funciona nada", que no es un problema de red ni de señal — es que la MAC nueva nunca se registró.

Bouquets: el catálogo no es una sola lista

Un error de diseño común es tratar el portal como si tuviera "un catálogo" que todos los dispositivos ven igual. En la práctica, la unidad de organización es el bouquet —un paquete de canales con su propio orden, categorías y reglas de acceso— y cada dispositivo (o grupo de dispositivos) se suscribe a uno o más bouquets. Esto es lo que permite, por ejemplo, tener un paquete básico y uno premium con canales adicionales, sin mantener dos portales separados: es el mismo catálogo maestro, con visibilidad distinta según a qué bouquet está asignada cada MAC.

Tres decisiones de armado de bouquets que se pagan caro si se improvisan:

• IDs de canal estables. El identificador interno de cada canal en el portal tiene que mapear siempre al mismo canal lógico en Flussonic, incluso si el nombre visible cambia (rebranding de un canal, por ejemplo). Si el ID cambia junto con el nombre, cualquier bouquet que lo referencie queda apuntando a un canal fantasma hasta que alguien lo reconstruye a mano.
• Categorías con profundidad razonable. STBs con control remoto simple navegan mal listas planas de 200+ canales. Agrupar por género/idioma dentro del bouquet no es cosmético — es la diferencia entre un cliente que encuentra su canal en tres clics y uno que llama a soporte porque "no encuentra nada".
• Orden explícito, no alfabético por defecto. El orden en que aparecen los canales dentro de una categoría debería reflejar lo que la audiencia real espera ver primero (canales generalistas arriba, nicho abajo), no el orden que el sistema asigna por defecto al cargar canales nuevos.

Apuntando a dos backends: dónde vive el failover

En una arquitectura con Flussonic primario y secundario en sitios distintos —el patrón que describimos en el post sobre failover geográfico— el portal es la pieza que decide, en tiempo real, a cuál de los dos backends manda al STB. La configuración de cada canal en Stalker no apunta a una sola URL fija: apunta a una lista de fuentes con prioridad, y el portal (o un chequeo de salud externo que alimenta esa configuración) determina cuál está sana antes de servir la respuesta al STB.

Esto es lo que hace que la conmutación sea casi invisible para el cliente: el STB no sabe ni le importa que el stream venga de un servidor en el Caribe o en Francia, solo pide "el canal 14" y el portal resuelve el resto. La alternativa —hardcodear la URL del backend primario en cada canal— funciona hasta el primer fallo, momento en el que hay que editar manualmente cientos de entradas de canal bajo presión, que es exactamente el escenario que el diseño con prioridades por fuente existe para evitar.

Errores de provisión que más tickets generan

1. MAC dada de alta en el bouquet equivocado

El síntoma es "el cliente ve canales pero le faltan varios". No es un problema de señal ni de portal caído — es que el dispositivo quedó suscrito al bouquet básico en vez del que corresponde a su plan. El primer paso de diagnóstico ante "me faltan canales" siempre debería ser revisar la asignación de bouquet de esa MAC específica, antes de tocar nada del lado de Flussonic.

2. Caché del STB sirviendo configuración vieja

El cliente Stalker en el firmware cachea la lista de canales y no siempre refresca de inmediato cuando el portal cambia algo (un canal que se movió de bouquet, una URL de backend actualizada). El síntoma es "en el portal ya está arreglado pero el STB del cliente sigue mal" — la solución operativa es reiniciar el STB o forzar un refresh de canal, no seguir tocando configuración que ya está correcta del lado del servidor.

3. Reloj del STB desincronizado

Los STBs MAG dependen de su propio reloj interno (normalmente sincronizado por NTP al encender) para varias cosas: validar la sesión con el portal, calcular qué programa "en vivo" mostrar en el EPG, y habilitar catch-up dentro de la ventana correcta. Un STB con reloj desfasado —por una red que bloquea NTP saliente, típicamente— puede mostrar EPG incorrecto o rechazar streams por token "expirado" cuando en realidad el token es válido y el reloj es el que está mal.

4. Bouquet premium sin canal de respaldo del backend correcto

Cuando se agregan canales nuevos a un bouquet existente, es fácil copiar la configuración de un canal parecido y olvidar actualizar la prioridad de fuentes al backend correcto para ese canal específico —sobre todo si algunos canales solo se capturan en un sitio (por ejemplo, un canal exclusivo del satélite del Caribe sin fuente equivalente en Francia). El resultado es un canal que funciona en condiciones normales y desaparece por completo, sin fallback, exactamente cuando el sitio primario tiene un problema.

Monitorear el portal es distinto a monitorear el stream

El monitoreo de canal por canal (bitrate en cero, señal perdida) que cubrimos en el post anterior valida que el backend esté sano. No valida que un STB nuevo pueda autenticarse, que un bouquet recién editado se sirva bien, o que el panel de administración responda. Son fallas independientes: Flussonic puede estar sirviendo los 40 canales perfectamente mientras el portal está caído o lento, y en ese escenario ningún cliente ve nada, aunque toda la señal esté sana.

Un chequeo mínimo y aparte para el portal —una petición sintética periódica que simula el handshake de un STB real contra una MAC de prueba, y valida que la respuesta llegue con el bouquet esperado dentro de un tiempo razonable— cierra ese punto ciego. Sin él, el primer indicio de que el portal tiene un problema es el mismo de siempre: el teléfono de soporte sonando.

Checklist antes de dar por lista la capa de distribución

• Cada MAC nueva se da de alta en el bouquet correcto antes de entregar el equipo, no después del primer reclamo.
• No hay MACs duplicadas entre lotes de STBs de proveedores distintos.
• Los IDs de canal en el portal son estables frente a cambios de nombre o rebranding.
• Cada canal con fuente en un solo sitio físico tiene esa limitación documentada, no asumida.
• Hay un chequeo sintético del handshake del portal, separado del monitoreo de bitrate de los canales.
• El proceso de reemplazo de equipo incluye explícitamente dar de baja la MAC vieja y alta la nueva.

Cierre

La captación y el procesamiento son donde vive la complejidad técnica más vistosa —muxes, perfiles ABR, redundancia geográfica—. El portal es donde vive la complejidad operativa: cientos de dispositivos individuales, cada uno con su propio estado de autorización, que hay que mantener correcto uno por uno sin que el mantenimiento se vuelva el cuello de botella de toda la plataforma. Tratar esa capa con el mismo rigor que la señal —procesos claros de alta y baja, monitoreo propio, catálogo bien estructurado— es lo que separa una plataforma que escala de una que necesita a alguien revisando bouquets a mano cada vez que algo no cuadra.

Si estás evaluando montar o auditar la capa de distribución de una plataforma IPTV —portal, provisión de STBs, doble backend— hablemos.