allow supplying a wb account access token in config so the session
joins as that account instead of an anonymous guest. when auth.token
is empty the provider falls back to the guest-register flow.
threads auth.token through config -> session -> server/client ->
transport -> engine builtin -> auth provider.
- add package and exported-method doc comments
- use errors.New for sentinel, drop unused nolint directives
- wrap AcceptTCP error
- fix errcheck/noctx in tests
- extract newSettingEngine to keep negotiatePC under complexity limit
WaitForPeer makes the client block before it sends its SYN, so the
server cannot yet know the client epoch and its first welcome arrives as
a broadcast (receiverEpoch=0). The same happens on every reconnect:
peerEpoch is reset to 0 and the peer re-announces via a broadcast
Send(nil). The strict requireTargetedPeer guard dropped those broadcasts
while unlatched, so peerEpoch never latched and WaitForPeer hung for its
whole timeout - the link connected and pinged but no data ever flowed
("ping works, no connection"), most visibly when a peer left and
reconnected. Accept a broadcast while unlatched (peerEpoch==0) and keep
rejecting third-party broadcasts once latched.
- bound WaitForPeer in bringUpLink/tryReopenSession to handshake timeout
so a missing peer fails fast instead of hanging before the SOCKS listener
- call waitForPeer on the reconnect path too: resetLinkPeer clears the peer
epoch, so without it the post-reconnect SYN re-races the server bridge
- restore strict requireTargetedPeer guard: the server always replies
targeted (it latches the client epoch from the SYN before smux replies),
so untargeted broadcasts before latch must be dropped
- remove per-frame debug logging on the bridge send/recv hot path
- extract buildSmuxClient / establishPeerSession helpers and wrap interface
errors to satisfy cyclop/nestif/wrapcheck
Client was racing ahead of the server by ~2s: it opened the smux SYN
right after bridge-ready, but JVB silently dropped those frames because
the server hadn't opened its datachannel yet. smux does not retransmit
SYN, so AcceptStream on the server side never returned and the handshake
timed out.
Add WaitForPeer (engine.PeerReadySession / transport.PeerReadyTransport)
that polls peerEpoch until the first epoch broadcast from the remote
side is received, then proceed to smux + handshake.
xmppKeepalive was using fire-and-forget Send(); on a half-open TCP
connection pings were sent but the missing reply went undetected,
leaving the session stuck. Switch to SendIQWait so a timeout triggers
a reconnect.
In peer-routing mode the server may send the initial welcome frame as a
broadcast (receiverEpoch=0) before it has learned the client's
localEpoch. The previous requireTargetedPeer guard dropped every
broadcast unconditionally. Tighten the guard: only drop frames whose
senderEpoch is unknown or belongs to a different peer; frames from the
already-latched peer are always accepted.
inject a clean VP8 keyframe every ~2s during bulk so the SFU keeps
forwarding the track instead of stalling after its decode timeout.
add RTCP interceptors and IPv4-only ICE, priority control/data mux,
publisher PC reconnect with stable control epoch, and longer smux
keepalive/liveness windows to survive the reconnect gap
After a session reinstall, the old client's control loop may have
already written a CONTROL_PING frame to the link before its context
was cancelled. This frame arrives at the server's new smux session and
is routed to the handshake stream (matching stream ID), where the
framing layer interprets the JSON bytes as an impossibly large length
prefix ('{\x22ve' = 2065856101 > 65536).
Previously this triggered a full reinstall, which could cascade into
a reconnect storm. Now acceptHandshake and acceptPeerHandshake
recognize ErrFrameTooLarge as a stale-frame artifact: they close the
polluted stream and retry AcceptStream up to 3 times, giving the real
CLIENT_HELLO a chance to arrive on the next stream.
The lightweight soft-rejoin path (jSess.Rejoin) skips Jicofo focus
allocation and joins the MUC with a bare presence. After the client
leaves and Jicofo idle-terminates the now-empty conference
(session-terminate <expired/>), the room/focus is torn down. A bare
rejoin presence is then rejected by Prosody with
<presence type='error'><not-allowed/>, and the library's JoinMUC matches
a stale status-110 left in its stanza buffer and falsely reports success.
The engine then waits forever for a session-initiate that never arrives
while actually being outside the room, so the client can never reconnect.
Re-establish the session from scratch via j.JoinMUC instead, which runs
dial -> focus allocation -> MUC join in the correct order (focus first,
so Jicofo recreates the room), exactly like the initial Connect, but
WITHOUT blocking on session-initiate. The fresh session-initiate is
awaited separately via WaitJingleReinitiate once a peer rejoins, so the
non-blocking reconnect contract is preserved.
Verified on a live deployment: two consecutive reconnect cycles now
complete (bridge open sctp -> reconnected -> session opened) where the
old path hung after "waiting for session-initiate".
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
j.Join() blocks on WaitJingle until Jicofo sends session-initiate,
which only happens when a second participant joins the room. With the
transport-level connect timeout (30-60s), the server crashes if no one
joins in time.
Switch to j.JoinMUC() which returns immediately after joining the MUC.
A background goroutine (waitForJingle) waits for session-initiate and
then opens the bridge + negotiates the PeerConnection. This way Connect
succeeds as soon as the XMPP connection is established, regardless of
whether another participant is present.
When the JVB bridge disconnects but the session is not yet closed
(e.g. during a pending reconnect), rtcpKeepalive spins indefinitely
logging "rtcp keepalive write: io: read/write on closed pipe" every
5 seconds. The process appears alive but is functionally dead —
systemd Restart=always never triggers and the instance becomes
permanently wedged.
Add an error counter that triggers requestReconnect after 3
consecutive WriteRTCP failures, allowing the supervisor to
tear down and re-establish the bridge connection. Reset the
counter on any successful write.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
neuronori