Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#2,220 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
43/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
android, kotlin
Lĩnh vực
backend-api-design, networking

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Kotlin
Star
3k
Fork
946
Merge trung bình
3 ngày 17 giờ
Pull request đã merge (30 ngày)
9

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của pedroSG94/RootEncoder

Tất cả issue của pedroSG94/RootEncoder

Issue tương tự

Thêm issue về Kotlin

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.