Tabla D1: webrtc_signaling — Canal de señalización WebRTC

Descripción

Tabla D1 (SQLite edge) creada en la migración 0035_webrtc_signaling.sql (s79, 22-05-2026). Almacena los mensajes de señalización efímeros que los browsers del workspace necesitan intercambiar para negociar conexiones WebRTC peer-to-peer.

Diseño para volatilidad: los mensajes tienen un TTL de 60 segundos. Una vez que dos peers han negociado su conexión (offer → answer → ICE), los mensajes ya no son necesarios. El cleanup se hace de forma inline en cada GET del endpoint, sin cron ni Worker dedicado.

Schema

CREATE TABLE IF NOT EXISTS webrtc_signaling (
  id          INTEGER PRIMARY KEY AUTOINCREMENT,
  room        TEXT    NOT NULL,
  from_peer   TEXT    NOT NULL,
  from_name   TEXT,
  to_peer     TEXT,
  kind        TEXT    NOT NULL CHECK (kind IN ('peer_joined','peer_left','offer','answer','ice')),
  payload     TEXT    NOT NULL DEFAULT '{}',
  created_at  TEXT    DEFAULT (datetime('now'))
);

Columnas

Columna	Tipo	Nullable	Descripción
`id`	INTEGER PK AUTOINCREMENT	No	Usado como cursor para paginación pull-incremental (`since=ID`)
`room`	TEXT	No	Identificador de la sala de reuniones
`from_peer`	TEXT	No	ID único del peer emisor (generado en cliente)
`from_name`	TEXT	Sí	Nombre del TeamMember (Edu/Dani/Txell). Validado contra CF Access.
`to_peer`	TEXT	Sí	Peer destino. `NULL` = broadcast (peer_joined/peer_left)
`kind`	TEXT CHECK	No	Tipo de señal. Ver enum abajo.
`payload`	TEXT (JSON)	No	SDP, ICE candidate, o `{}` para presencia
`created_at`	TEXT (datetime)	No (default now)	Timestamp UTC para TTL cleanup

Enum `kind`

Valor	`to_peer`	Descripción
`peer_joined`	NULL	Broadcast: un peer entró a la sala. Invita a otros a iniciar offer.
`peer_left`	NULL	Broadcast: un peer salió. Los demás cierran su RTCPeerConnection.
`offer`	peer ID	SDP offer dirigido a un peer específico (initiator → responder)
`answer`	peer ID	SDP answer dirigido al initiator
`ice`	peer ID	ICE candidate para completar la negociación de conectividad

Lógica initiator: el peer con ID lexicográficamente menor actúa como initiator (envía el offer). Esto evita el “glare” (ambos enviando offer simultáneamente).

Índices

CREATE INDEX idx_webrtc_room_created ON webrtc_signaling(room, created_at);
CREATE INDEX idx_webrtc_to_peer      ON webrtc_signaling(to_peer, created_at);

idx_webrtc_room_created: optimiza el GET (filtro por room + cleanup TTL).
idx_webrtc_to_peer: optimiza la búsqueda de mensajes dirigidos a un peer concreto.

TTL y cleanup

DELETE FROM webrtc_signaling
WHERE created_at < datetime('now', '-60 seconds')

Ejecutado inline en cada GET y POST de /api/webrtc/signal. No hay cron ni Durable Object dedicado. El volumen es muy bajo (máx. 3 peers × ~10 mensajes/negociación = ~30 rows por sesión, todas borradas en 60s).

Migración

Archivo: migrations/0035_webrtc_signaling.sql
Número: 0035
Sesión: s79 (22-05-2026)
Base de datos: D1 del workspace (Cloudflare Pages)

Volumen esperado

En condiciones normales (3 peers, 1 sala):

~15–30 rows durante la negociación inicial (~5–10s).
0 rows a los 60s (cleanup automático).
Sin crecimiento acumulativo.

Véase también

[[entity—workspace—endpoint—webrtc-signal]]
[[feature—workspace—webrtc-peer-to-peer]]
[[decision—20260522—webrtc-reemplaza-jitsi]]
[[workspace—que-es-workspace]]