Llevar vídeo en directo a una plataforma de hogar inteligente, de la prueba de concepto a la escala real

Contexto

La plataforma ya existente de un proveedor de dispositivos para hogar conectado estaba construida en torno a protocolos inalámbricos de corto alcance: termostatos, cerraduras, iluminación y sensores similares, todos comunicándose sobre una red mallada de bajo consumo ya establecida. Una cámara era algo categóricamente distinto: vídeo IP continuo por WiFi, el primer dispositivo de ese tipo en la plataforma, y la infraestructura existente no tenía ningún soporte para ello.

Naeva Tec entró en juego para la parte de medios de ese problema: convertir el vídeo en bruto de una cámara IP de consumo en algo que la propia app móvil del proveedor pudiera mostrar en directo, almacenar y reproducir después, sin pedirle al resto de una plataforma ya madura que cambiara de forma para dar cabida a ello.

Demostrarlo primero, en menos de dos segundos

Antes de comprometerse con una construcción completa, el proveedor quería una prueba de concepto con objetivos claros y medibles:

• Streaming en directo desde la cámara.
• Grabaciones activadas por movimiento, subidas automáticamente a la nube.
• Selección y reproducción de grabaciones.
• Una app móvil que ejercitara todo lo anterior de principio a fin.
• Latencia por debajo de dos segundos, tanto para la visualización en directo como para la reproducción.
• Una arquitectura que pudiera escalar de forma plausible a un millón de cámaras más adelante, aunque la propia prueba de concepto solo fuese a ejecutar un puñado de ellas.

Construimos esto sobre Kurento Media Server: un servidor de control en Java suscrito a los eventos generados por la cámara a través de MQTT, una ruta de medios RTSP de entrada y WebRTC de salida para la visualización en directo, un repositorio de grabaciones respaldado por S3, y una API REST que alimentaba una pequeña app móvil nativa construida específicamente para validar el concepto, deliberadamente separada de la app de producción del propio proveedor para poder demostrar el pipeline de medios de forma casi aislada primero.

De la prueba a la producción

Una vez que el concepto se sostuvo, el trabajo pasó a una construcción completa junto al propio equipo de ingeniería del proveedor, entregada sprint a sprint como parte de su proceso ágil ya existente, en lugar de como un proyecto aparte y aislado. El alcance creció en consecuencia:

• Integración real con la propia plataforma de mensajería de dispositivos del proveedor, en sustitución del pipeline aislado de la prueba de concepto.
• Trabajo de escalabilidad y despliegue dimensionado de verdad para hasta un millón de cámaras, no un puñado.
• Ajuste de bitrate adaptativo, de forma que el stream de una cámara se degrada con elegancia en una conexión débil en lugar de bloquearse.
• Integración de monitorización, para que las herramientas operativas que el proveedor ya usaba para el resto de su plataforma también pudieran ver el nuevo tráfico de cámaras.
• Soporte continuo para las propias apps móviles del proveedor a medida que añadían visualización en directo, grabaciones y alertas de movimiento para los usuarios finales.

Nuestro papel

• Diseñar y construir el pipeline de Kurento Media Server y el servidor de control, desde la prueba de concepto hasta la escala de producción.
• Gestionar la señalización y el ciclo de vida RTSP de entrada / WebRTC de salida para cada sesión de cámara.
• Construir el pipeline de eventos que convertía los eventos de movimiento y audio generados por la cámara en grabaciones almacenadas y notificaciones push al usuario correcto.
• Ajustar la ruta de medios (bitrate adaptativo, latencia en directo por debajo de dos segundos) para una plataforma pensada para llegar a soportar un millón de dispositivos.
• Trabajar integrados en los propios equipos de sprint del proveedor durante la fase de producción, no como un proveedor externo trabajando de forma aislada.

Tecnologías

• Kurento Media Server, para el relevo de medios entre cámara y espectador y para la grabación.
• Un servidor de control en Java (Spring Boot), encargado del procesamiento de eventos y de la API REST.
• MQTT, para la señalización de eventos entre la cámara y la nube.
• AWS (EC2 y S3), para el cómputo y el almacenamiento de grabaciones.
• APIs REST con payloads JSON, y clientes móviles nativos (iOS, más adelante Android) consumiéndolas.
• Notificaciones push, entregando eventos de movimiento y audio al dispositivo del usuario correcto.

Conclusión y lecciones aprendidas

Demostrar primero, de forma aislada, la parte más difícil (streaming en directo de baja latencia y grabación a la escala de una cámara IP de consumo) permitió a ambas partes validar las suposiciones de mayor riesgo (soporte de códecs, latencia, escala futura) antes de que ese trabajo tuviera que competir con todo lo demás ya construido en una plataforma madura. También dejó ver pronto la lección más difícil: añadir un tipo de dispositivo genuinamente nuevo a un ecosistema que nunca se diseñó para ello raramente es solo un problema de medios, y la fase de producción, integrados directamente en el propio equipo del proveedor, fue donde ese trabajo de integración realmente ocurrió.