WHIP client can't connect to `a=ice-lite` + `a=setup:passive` servers (e.g. Cloudflare Stream)

Abierto
  • ¿Algo no está bien?
#2,220 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
43/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
android, kotlin
Área
backend-api-design, networking

Línea de trabajo

Start in whip/src/main/java/com/pedro/whip/dtls/ and the WHIP ICE nomination and teardown paths; the issue names only the DTLS directory, so locate the parsed SDP answer and sender code from there. Reproduce with a Cloudflare Stream WHIP input and inspect the ICE and DTLS flow for a=ice-lite and a=setup:passive. Done means the connection nominates, completes DTLS, sends media, and closes promptly; also check the non-zero-offset send behavior described in the issue.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

The beta whip client can publish to WHIP servers that answer a=setup:active and send a full ICE agent's STUN checks (e.g. MediaMTX), but it cannot connect to a WHIP server that answers a=ice-lite and a=setup:passive — the configuration Cloudflare Stream (and other lite/SFU-style ingest endpoints) use. Two independent causes, plus a couple of smaller related bugs. I have a working patched copy and am happy to open a PR if the direction looks right.

Environment
  • RootEncoder 2.8.1 (also verified against current master: whip/src/main/java/com/pedro/whip/dtls/ still contains only DtlsConnection — server role — so this is not fixed on master).
  • WhipStream publishing to a Cloudflare Stream WebRTC (WHIP) live input.
  • Android 14/15, hardware H.264 Constrained Baseline, video-only and A/V both reproduce it.
What happens
  1. The HTTP POST signaling succeeds (201), SDP answer parsed.
  2. The first STUN binding exchange succeeds.
  3. ...then it stalls silently — never nominates, never starts DTLS. With the server role in play, even once ICE is forced it never handshakes, because the server is setup:passive and waits for our ClientHello which never comes.
Root cause 1 — waits for an inbound STUN request that an ice-lite agent never sends

After the first successful STUN binding, the client loops waiting to also receive an inbound STUN request from the peer before nominating. An a=ice-lite agent is passive and does not send connectivity checks, so that wait never completes and the connection hangs.

Fix: when the answer contains a=ice-lite, skip waiting for the peer's request and proceed to nominate immediately. (Needs ice-lite surfaced from the parsed answer.)

Root cause 2 — no DTLS client role

whip/dtls/ provides only DtlsConnection (DTLS server role), which works when the answer is a=setup:active (the peer opens the handshake). Cloudflare answers a=setup:passive and waits for the offerer to send the ClientHello, so a DTLS client role is required and currently doesn't exist.

Fix: add a DTLS client connection (BouncyCastle DTLSClientProtocol) alongside the server one, with the same use_srtp profile (SRTP_AES128_CM_HMAC_SHA1_80), server-certificate fingerprint verification, and exported keying material; choose the role from the answer's a=setup: value and have the sender use the client half of the exported keys for passive peers.

The server's SDP answer (Cloudflare, redacted)
v=0
o=- <id> <ver> IN IP4 0.0.0.0
s=-
t=0 0
a=msid-semantic:WMS*
a=fingerprint:sha-256 <redacted>
a=ice-lite
a=group:BUNDLE 0
m=video 9 UDP/TLS/RTP/SAVPF 96
c=IN IP4 0.0.0.0
a=setup:passive
a=mid:0
a=ice-ufrag:<redacted>
a=ice-pwd:<redacted>
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; sprop-parameter-sets=...; profile-level-id=42c01f
a=recvonly
a=candidate:<n> 1 udp 2130706431 <host> <port> typ host
a=end-of-candidates

Note a=ice-lite + a=setup:passive together — this is the combination that is unsupported today.

Smaller related issues found while fixing the above
  • DtlsTransport.send(buffer, offset, length) slices offset until length instead of offset until offset + length, corrupting any write with a non-zero offset.
  • Teardown after #2126: the WHIP DELETE is sent, but the DTLS close_notify doesn't reach the server because the media socket is closed (via whipSender.stop(), which closes the shared UdpStreamSocket) before DtlsConnection.close() runs. Closing DTLS while the socket is still open lets the server drop the publisher promptly instead of waiting out its own ICE/DTLS timeout. (With Cloudflare this manifested as the live input showing connected for ~40–55 s after a clean stop.)
  • A short DTLS handshake timeout (5 s) is tight over LTE with RSA-2048; ~10 s is more reliable.
Reproduce
  1. Create a Cloudflare Stream WebRTC live input; take its WHIP publish URL (…/webRTC/publish).
  2. Publish with WhipStream (H.264 Constrained Baseline 42e01f).
  3. Observe: 201 from the POST, one successful STUN exchange, then no nomination / no DTLS / no media.
Proposed fix / offer

I have a working implementation (ice-lite skip + a DtlsClientConnection selected by a=setup:, plus the two small fixes above) and would be glad to submit it as a focused PR that leaves the existing active/server path untouched. These changes are general to any ice-lite + setup:passive WHIP server, not Cloudflare-specific — Cloudflare is just the concrete repro. One open discussion point: I also had to use an unconnected UDP socket for the media path, because a connected DatagramSocket dropped Cloudflare's media/DTLS datagrams (they return from a different source port than the one we send to); happy to discuss whether that belongs upstream or is environment-specific.

Lenguaje dominante
Kotlin
Estrellas
3k
Forks
946
Merge medio
3 d 17 h
PR fusionados (30 d)
9

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pedroSG94/RootEncoder

Todos los issues de pedroSG94/RootEncoder

Issues similares

Más issues de Kotlin

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.