Are there any known issues with Janus and DTLS 1.3? BoringSSL is now using DTLS 1.3 by default since half a year and we possibly experienced an edge case with publishers on a poor connection where they think they were publishing with completed DTLS handshake, but subscribers didn’t receive anything.
What goes wrong in the handshake:
On a publishing connection the browser offers, Janus answers, and Janus takes the DTLS client role. The sequence for the failing Chrome join:
Claude analysis of the situation follows:
Four facts, each checked in the source at the versions the media team runs, combine into the failure:
- The handshake is DTLS 1.3. Janus never sets a maximum version, and BoringSSL has defaulted to DTLS 1.3 since 12 February 2026. Healthy joins on this server show DTLS 1.3 in the browser stats.
- BoringSSL calls the client handshake done as soon as it writes its last message, before the browser confirms receipt. Janus then logs “handshake completed” and announces the publisher.
- BoringSSL still expects to be told when to resend that message, until the browser confirms it. Only Janus’s periodic timer call does that.
- Janus stops that timer the moment it considers the handshake done. Its 20-second handshake timeout sits behind the same check, so it never fires either.
A second safety net is also missing: when the browser repeats its reply, the DTLS 1.3 standard (RFC 9147 §5.8.1) says the other side should resend. BoringSSL drops those repeats, and its code carries an open TODO for exactly this. Fixing either Janus or BoringSSL would be enough to heal the loss.