Protocolos: WebRTC & Mumble

Ficha Técnica: Stack WebRTC

Capa	Protocolo	Puerto	Función
Señalización	SDP (Session Description Protocol)	Fuera de banda	Negociación de capacidades y direcciones
Descubrimiento	ICE (RFC 8445)	Dinámico UDP	Encontrar la mejor ruta entre peers
NAT traversal	STUN (RFC 8489) / TURN (RFC 8656)	3478 / 443	Resolver IP pública / relay
Transporte seguro	DTLS 1.2 (RFC 6347)	Sobre ICE	Handshake criptográfico, intercambio de claves
Media	SRTP (RFC 3711)	Sobre DTLS	Audio/vídeo cifrado (Opus, VP8/H.264)
Datos	SCTP (RFC 4960) sobre DTLS	Sobre DTLS	DataChannels: mensajes fiables u ordenados
Codecs oblg.	Opus (audio), VP8 (vídeo)	—	Mínimo común garantizado por spec

RFCs: W3C WebRTC 1.0 · RFC 8825 Overview · RFC 8829 JSEP · RFC 8831 Data Channels · RFC 8826 Security

§1.1 — Señalización: Oferta y Respuesta (SDP)

WebRTC no define el canal de señalización — eso es "fuera de banda" (HTTP, WebSocket, SSB, formulario HTML…). Lo que sí define es el formato: SDP.

Peer A                     Señalización                      Peer B
══════                  (cualquier canal)                    ══════
  │                                                            │
  │── createOffer() ─────────────────────────────────────────>│
  │   (SDP: codecs, ICE candidates, fingerprint DTLS)          │
  │                                                            │
  │                                        setRemoteDescription(offer)
  │                                        createAnswer()
  │                                                            │
  │<──────────────────────────────────── answer (SDP) ────────│
  │                                                            │
  │   setRemoteDescription(answer)                             │
  │                                                            │
  │◄═══════════ DTLS handshake + SRTP/SCTP ══════════════════►│
  │                  Canal abierto                             │

El SDP contiene: codecs soportados, candidatos ICE (IPs:puertos), fingerprint del certificado DTLS, y los media tracks ofrecidos.

§1.2 — Tres Capas de Comunicación

                ┌──────────────────────────────────┐
                │      Señalización (SDP)          │
                │  (HTTP, WebSocket, SSB, manual)  │
                └────────┬─────────────────────────┘
                         │ establece
      ┌──────────────────┼──────────────────────┐
      │                  │                      │
┌─────┴──────┐   ┌───────┴────────┐   ┌────────┴───────┐
│ DataChannel│   │ Media Stream   │   │    Files       │
│   (SCTP)   │   │   (SRTP)       │   │  (SCTP bin)    │
│            │   │                │   │                │
│ mensajes   │   │ audio: Opus    │   │ arraybuffer    │
│ texto/bin  │   │ vídeo: VP8/H264│   │ chunked        │
│ chat, JSON │   │ tracks         │   │ con progreso   │
└─────┬──────┘   └───────┬────────┘   └────────┬───────┘
      │                  │                      │
      └──────────────────┼──────────────────────┘
                         │
              ┌──────────┴──────────────────────┐
              │ Transporte: DTLS-SRTP sobre ICE │
              │        (peer-to-peer)           │
              └─────────────────────────────────┘

Las 3 capas comparten el mismo canal ICE (misma conexión UDP), multiplexadas por DTLS. La señalización solo interviene al inicio — después, todo el tráfico es directo.

§1.3 — ICE: Descubrimiento de Ruta

ICE (RFC 8445) encuentra la mejor ruta entre dos peers en 3 fases.

Fase	Qué hace	Detalle
1. Gathering	Recopilar candidatos	host: IPs locales (192.168.1.50:54321) srflx: IP pública vía STUN (85.34.22.10:54321) relay: dirección TURN (turn.example.com:443)
2. Checks	Probar pares de candidatos	STUN Binding Requests directos entre peers. Cada par recibe prioridad calculada.
3. Nomination	Elegir ruta activa	Par con mejor prioridad + conectividad. Si la red cambia → ICE restart.

En LAN, el candidato host conecta directamente en milisegundos. En WAN entran STUN y TURN.

§1.4 — STUN: IP Pública

  Cliente              Servidor STUN
  ═══════              ═════════════
    │                        │
    │── Binding Req (UDP) ──>│
    │                        │ (ve IP:puerto
    │                        │  tras el NAT)
    │<── Binding Response ───│
    │ XOR-MAPPED-ADDRESS:    │
    │ 85.34.22.10:54321      │
    │                        │

Solo pregunta-respuesta. STUN no retransmite tráfico — solo dice "tu IP pública es X".

Servidores públicos:
stun:stun.l.google.com:19302
stun:stun.stunprotocol.org:3478

§1.5 — TURN: Relay

Peer A         TURN           Peer B
══════         ════           ══════
  │              │              │
  │─ Allocate ──>│              │
  │<─ relay addr │              │
  │              │              │
  │═ datos ═════>│═══ relay ═══>│
  │<═════════════│<═════════════│
  │  (todo pasa por TURN)       │

Fallback cuando STUN falla (NATs simétricos, firewalls). TURN sí retransmite todo el tráfico — consume BW y CPU en el servidor.

ICE siempre prefiere host → srflx → relay (último recurso).

Ficha Técnica: Stack Mumble

Mumble es un sistema VoIP completo con >20 años de madurez, ya desplegado en el SNH (~10 MB RAM). Su protocolo condiciona la arquitectura.

Capa	Protocolo	Puerto	Función
Control	TCP + TLS 1.2 (AES-256-SHA)	64738	Auth, canales, ACLs, estado users, chat texto
Voz	UDP + OCB-AES128	64738	Audio Opus/CELT cifrado, ~20–50 ms latencia
Voz fallback	TCP tunnel	64738	Voz sobre TCP cuando UDP no funciona (NAT/Tor)
Serialización	Protocol Buffers (Mumble.proto)	—	Mensajes de control tipados y extensibles
Codec	Opus (desde v1.2.4, 2013)	—	Mismo codec que WebRTC
Cifrado voz	OCB-AES128 (AEAD)	—	Confidencialidad + integridad en un solo paso
Auth	Cert X.509 del cliente + username	—	TLS mutuo opcional

Flujo de Conexión Mumble

Mumble Client                              murmurd (servidor)
══════════════                             ═══════════════════
     │                                              │
     │── TCP connect ──────────────────────────────>│
     │── TLS handshake (AES-256-SHA) ─────────────>│
     │<─ TLS established ─────────────────────────│
     │                                              │
     │── Version (protobuf) ──────────────────────>│
     │── Authenticate (user, cert, tokens) ───────>│
     │<─ CryptSetup (key, nonce para OCB-AES128) ─│
     │<─ ChannelState[] (árbol de canales) ───────│
     │<─ UserState[] (usuarios conectados) ───────│
     │<─ ServerSync (session_id, permisos) ───────│
     │                                              │
     │══ UDP ping ════════════════════════════════>│
     │<═ UDP pong ════════════════════════════════│
     │                                              │
     │══ Voice (Opus, OCB-AES128, UDP) ══════════>│
     │<═ Voice (otros users, Opus, UDP) ═════════│
     │                                              │
     │   [si UDP falla → voice tunnel sobre TCP]    │

¿Por Qué Mumble Importa para el SNH?

#	Propiedad	Detalle
1	Opus compartido	Tanto Mumble como WebRTC usan Opus. No hay conversión de codec necesaria.
2	Cifrado mandatorio	TLS para control, OCB-AES128 para voz. No existe modo sin cifrar.
3	TCP fallback nativo	Cuando UDP falla (NAT simétrico, Tor), Mumble tuneliza voz por TCP automáticamente. Lo que WebRTC resuelve con TURN, Mumble lo resuelve gratis.
4	Funciona sobre Tor	TCP tunnel sobre hidden services. WebRTC sobre Tor es problemático (ver §2.3).
5	Ya instalado	murmurd ya corre en el SNH (~10 MB RAM). Coste incremental: cero.

★ Mumble resuelve gratis (TCP fallback + Tor + cifrado) lo que WebRTC necesita TURN + configuración extra ★

WebRTC vs. Mumble — Cara a Cara

	WebRTC	Mumble
Función	Audio + vídeo + datos P2P	Audio VoIP (solo audio)
Codec audio	Opus (obligatorio)	Opus (desde 2013)
NAT traversal	ICE + STUN + TURN	TCP fallback automático
Tor	Problemático (UDP, leaks)	✔ TCP tunnel nativo
Cifrado	DTLS + SRTP (obligatorio)	TLS + OCB-AES128 (obligatorio)
Vídeo	✔ VP8/H.264	✘ Solo audio
DataChannels	✔ SCTP sobre DTLS	✘ Solo texto por TCP control
En el SNH	Requiere instalar lib	Ya instalado (murmurd :64738)

No son excluyentes: en escenario remoto + Tor, la Arq. 3 combina ambos — Mumble para audio, WebRTC/go2rtc para vídeo. Ver poster Arq. 3.

Pipeline de Transmisión por Pista

Pista	Captura	Codec	Unidad	Protocolo
Datos	Texto/JSON (formulario HTML)	N/A	Mensajes SCTP ≤256 KB	SCTP sobre DTLS
Audio	ffmpeg -f alsa/pulse (mic)	Opus 48 kHz	Paquetes RTP 20 ms (~160 B)	SRTP sobre DTLS
Vídeo	ffmpeg -f v4l2 (cámara)	VP8 o H.264 HW	Paquetes RTP ~1200 B	SRTP sobre DTLS
Archivos	Buffer desde disco	N/A	Chunks binarios DataChannel	SCTP (fiable, ordenado)

La captura varía según CSI/USB — ver CSI vs. USB y spec pipeline.

Ficha Técnica: Stack WebRTC

§1.1 — Señalización: Oferta y Respuesta (SDP)

§1.2 — Tres Capas de Comunicación

§1.3 — ICE: Descubrimiento de Ruta

§1.4 — STUN: IP Pública

§1.5 — TURN: Relay

Ficha Técnica: Stack Mumble

Flujo de Conexión Mumble

¿Por Qué Mumble Importa para el SNH?

WebRTC vs. Mumble — Cara a Cara

Pipeline de Transmisión por Pista

☞ Continúa Explorando