Alexei Rojas Quiroga
← Todos los proyectos

Proyecto personal

CameraDesk

Visor de escritorio para la nube de una cámara de consumo, con proxy de señalización y WebRTC

Estado
Prototipo
Rol
En solitario: análisis de protocolo, proxy Node, visor web, cliente MAUI

Arquitectura

  • Protocolo del fabricante reconstruido
  • Relay WebSocket TLS construido a mano
  • Video en vivo con WebRTC
  • Clientes web y de escritorio

La página inicia sesión y despierta la cámara por la capa Express, obtiene un ticket de la API del fabricante, negocia por el socket de señalización retransmitido y luego recibe el medio de la cámara.

Arquitectura · 6 nodos · 1 flujos
LO QUE CONSTRUÍHTML · WebRTCVisor webVista en vivo conRTCPeerConnectionExpress 5API de controlLogin, estado, controly ticketNode · TLS Web…Relé deseñalizaciónRetransmite tramas deseñalizaciónHTTPSAPI en la nube delfabricanteCuenta, equipo y ticketWebRTCWebSocketSeñalización delfabricanteEstablecimiento de lasesión WebRTCWebRTCCámaraTransmite medios envivo1login, OTP, wake-up, ticket,estado, control23456
  • Servicio / cómputo
  • Cliente
  • Sistema externo
  • Síncrono
  • Asíncrono / bucle
Desplázate hacia los lados para ver todo el diagrama

Cómo fluye, paso a paso

Haz clic en un paso para saltar a él. Haz clic en un componente para ver detalles.

Qué hace

Un experimento personal para ver una cámara doméstica desde una app de escritorio. Un backend Node/Express inicia sesión en la nube del fabricante, obtiene tickets WebRTC y retransmite el WebSocket de señalización, mientras una página web y una app .NET MAUI para Mac Catalyst actúan como clientes.

El problema

El fabricante de la cámara solo ofrece apps móviles. El objetivo era un visor de escritorio con estado y controles del dispositivo, lo que exigió entender el flujo no documentado de login, verificación y ticket WebRTC.

Qué construí

  • Reconstrucción del flujo de login, verificación OTP y ticket WebRTC del fabricante a partir de tráfico capturado y análisis de la app.
  • Capa REST con Express que expone endpoints de sesión, login, estado del dispositivo, atributos, control, hibernación y ajustes de IA.
  • Proxy WebSocket propio que construye a mano el handshake de upgrade y los frames para retransmitir la señalización al fabricante por TLS.
  • El cliente web negocia WebRTC con RTCPeerConnection; una app MAUI separada con configuración y modelos HTTP tipados apunta a macOS.

Decisiones clave y por qué

01

Proxy local en vez de llamar al fabricante desde el navegador

Una capa en el servidor puede fijar las cabeceras y formas de petición que espera la API del fabricante y manejar el upgrade WebSocket que los navegadores no pueden personalizar.

02

Endpoints configurables en appsettings

El cliente MAUI guarda rutas de API e interruptores de sondeo en opciones tipadas, de modo que los experimentos de protocolo cambian sin recompilar código.

03

Dos clientes sobre un mismo contrato de backend

Un visor web sin build permitió iterar rápido en WebRTC, mientras la app MAUI explora una experiencia nativa de escritorio.

Stack tecnológico

Lenguajes
JavaScript (Node.js)C# / .NET 10
Frontend
.NET MAUI (Mac Catalyst)WebRTC
Backend
Express 5
Mensajería
ws (WebSocket)
Otros
mitmproxy traffic analysis