Entrevista de backend: ¿Cómo diseñarías un endpoint de ingesta WebRTC seguro mediante WHIP?

Consigna y contexto

Necesitas un endpoint WHIP (WebRTC-HTTP Ingestion Protocol) para un codificador o productor de medios. El cliente envía una oferta application/sdp mediante HTTP POST; el servidor negocia ICE y DTLS y devuelve una respuesta SDP. Explica la API, el ciclo de vida de la sesión, la autenticación, la protección de recursos y la observabilidad. Asume una ingesta de medios unidireccional; la grabación y la transcodificación quedan fuera del alcance.

Qué evalúa el entrevistador

• Si los recursos de señalización HTTP y los recursos de medios WebRTC se modelan por separado.
• Si un POST conduce a un orden concreto de autenticación, límites, tiempos de espera (timeouts) y limpieza.
• Si el candidato comprende el límite entre HTTPS, ICE, DTLS-SRTP y las API del navegador en lugar de tratar a WHIP como un transporte de medios.
• Si se cubren los reintentos, la creación duplicada, las sesiones semiabiertas (half-open) y el SDP malicioso.

Preguntas de clarificación

• ¿El publicador es un codificador controlado o un usuario abierto? ¿Las credenciales pueden ser de corta duración y para un solo flujo?
• ¿El endpoint es regional o multirregión? ¿El estado de la sesión puede moverse entre regiones?
• ¿La prioridad es la baja latencia o se debe garantizar la completitud de la grabación y la capacidad de reproducción?
• ¿Se admitirá trickle ICE u otra extensión de WHIP, y quién es responsable de su negociación y autorización?

Respuesta en 30 segundos

Dividiría el endpoint en una pasarela de autenticación, un plano de control de sesiones y nodos de medios WebRTC. La pasarela verifica una credencial de corta duración, los límites de solicitudes y la cuota de inquilino (tenant) antes de pasar la oferta SDP al servicio de sesiones. El servicio asigna recursos acotados, completa ICE/DTLS y devuelve 201 Created, una respuesta SDP y un Location de sesión. Toda negociación incompleta debe liberar recursos; DELETE es idempotente y los límites se aplican por inquilino y por origen. Mediría la señalización HTTP, el estado de ICE/DTLS y la latencia del primer paquete de medios por separado, en lugar de usar el éxito del POST como métrica de disponibilidad.

Solución paso a paso

1. Establecer el límite del protocolo. WHIP realiza un intercambio HTTP de oferta/respuesta; luego, WebRTC transporta los medios. W3C expone los controles del navegador, mientras que el servidor sigue gestionando ICE, DTLS y la recepción de medios.
2. Realizar comprobaciones económicas primero. Antes de asignar nodos ICE o de medios, verifica HTTPS, autenticación, estado del inquilino, Content-Type: application/sdp, tamaño de la solicitud, autorización del canal y cuota de tasa (rate quota). Un rechazo no debe desencadenar un análisis SDP costoso ni la asignación de conexiones.
3. Modelar un recurso de sesión. Utiliza una URL de sesión aleatoria y no enumerable con pending → connected → closing → closed. La creación devuelve 201 Created, Location y una respuesta SDP; los errores deben ser diagnosticables sin exponer la topología interna.
4. Acotar el trabajo semiabierto. Establece límites de tiempo independientes para el análisis de SDP, el establecimiento de ICE/DTLS y el primer paquete de medios. El RFC 9725 advierte sobre la saturación por POST (POST flooding): un atacante con credenciales puede forzar asignaciones y esperar a que expiren los timeouts de ICE/DTLS. Aplica límites de tasa en el borde, cuotas de concurrencia de sesiones y recuperación por timeout.
5. Gestionar reintentos y eliminación. Los reintentos de red pueden enviar la misma oferta más de una vez. Vincula las credenciales a un canal o clave de idempotencia; si no se puede demostrar la igualdad, crea una nueva sesión solo bajo el límite de concurrencia. Haz que DELETE /session sea idempotente y devuelva el mismo estado terminal en llamadas repetidas.
6. Proteger el transporte y las credenciales. El RFC 9725 exige HTTPS para preservar el modelo de seguridad de WebRTC. Mantén las credenciales fuera de las cadenas de consulta (query strings) y registra únicamente identificadores de sesión hasheados. Los nodos de medios deben aceptar autorizaciones de corta duración del servicio de sesiones en lugar de una clave de canal ampliamente copiada.
7. Negociar extensiones explícitamente. Si se admiten trickle ICE o eventos del servidor, anuncia la capacidad mediante mecanismos como Link; los clientes no deben asumir que todos los servidores WHIP lo admiten. Si falla una extensión, recurre al intercambio base o finaliza explícitamente.
8. Probar el límite real de disponibilidad. Rastrea la aceptación de POST a nivel de inquilino, fallos de análisis de SDP, éxito de ICE, tiempo de configuración de DTLS, latencia del primer paquete de medios, recuperación por timeout y latencia de DELETE. Inyecta POST duplicados, SDP sobredimensionado, ICE inalcanzable, reinicios de nodos y revocación de credenciales.

Respuesta modelo

Primero plantearía esto como un endpoint del plano de control: HTTP POST entrega una oferta SDP al servicio de sesiones, mientras que WebRTC transporta los medios posteriormente. La pasarela verifica HTTPS, una credencial de corta duración, el permiso del canal, el tipo de contenido, el tamaño y la concurrencia del inquilino antes de analizar el SDP; cada rechazo ocurre antes de que se asignen los recursos de medios. Una solicitud exitosa crea una sesión no enumerable, devuelve 201 Created, Location y la respuesta, y entra en un estado pendiente temporizado. Si ICE o DTLS nunca se completan, el servicio recupera los candidatos y los nodos para que las sesiones semiabiertas no agoten la capacidad. DELETE es idempotente, y las credenciales de corta duración junto con una clave de idempotencia acotan los reintentos. Separaría las métricas de HTTP, ICE/DTLS y del primer paquete de medios, para luego realizar pruebas de carga con saturación de POST, SDP hostil, reinicios y revocación de credenciales para demostrar tanto la seguridad como la recuperación.

Errores comunes

• Tratar a WHIP como el canal de medios → El estado de ICE, DTLS y de los nodos desaparece del diseño → separar los planos de control y de medios.
• Asignar un nodo completo en cada POST → Las solicitudes hostiles acumulan trabajo semiabierto → realizar primero comprobaciones económicas y cuotas escalonadas.
• Usar únicamente un límite de tasa global → Un solo inquilino o canal afecta a todos → limitar por inquilino, credencial, canal y origen.
• Registrar SDP en bruto → Las direcciones y la topología pueden filtrarse → registrar un digest, la clase de error y el ID de correlación.
• Hacer que DELETE no sea idempotente → Los reintentos generan carreras de limpieza y errores 404 ruidosos → definir estados terminales y respuestas repetibles.
• Devolver HTTP 200 para cada resultado → Los clientes no pueden distinguir entre creación, rechazo y reintento → usar estados semánticos y cuerpos de error seguros.

Preguntas de seguimiento y respuestas

Un atacante tiene una credencial válida y sigue haciendo POST. ¿Cómo proteges el servicio?

Vincula la credencial a un inquilino, canal y expiración; aplica un bucket de tokens y un límite máximo de concurrencia en el borde, y luego limita las sesiones pendientes y el tiempo de espera total en el plano de control. Revoca las credenciales que crucen repetidamente el umbral y conserva registros de auditoría.

ICE tiene éxito pero DTLS nunca lo logra. ¿Reintentas o reportas éxito?

El éxito de ICE no significa que los medios estén listos. Mantén la sesión pendiente hasta que DTLS y una condición de primer paquete de medios se cumplan; al agotarse el tiempo de espera, ciérrala, devuelve una clase de fallo reintentable y libera candidatos y nodos.

El cliente envía la misma oferta SDP dos veces. ¿Cómo evitas la ingesta duplicada?

Exige una clave de idempotencia de corta duración y vincúlala a la credencial, el canal y el digest de la oferta. Devuelve la sesión original si se comprueba el duplicado. Si no se puede probar la equivalencia, crea una nueva sesión solo dentro de la cuota de concurrencia.

¿Puede una sesión WHIP trasladarse a otra región durante una interrupción?

Por lo general, una sesión ICE/DTLS establecida no puede trasladarse de forma transparente. El nuevo endpoint debe emitir una nueva URL de sesión, el cliente debe hacer POST nuevamente y la sesión anterior debe liberarse por tiempo de espera o mediante un DELETE explícito. El estado de credenciales replicado no debe ampliar el alcance de exposición.