VAPI-3929: republish retained streams after a websocket reconnect

[stampercasey]

Summary

When the gateway closes an endpoint's websocket (deploy-drain eviction, instance shutdown, media-server loss, heartbeat death), the SDK auto-reconnects and re-emits init, which rebuilds a fresh, trackless publishing peer connection. Nothing replayed the already-published local streams onto it, so the reconnected session came up half-alive: websocket connected, both peer connections connected, SIP parking leg re-established and acked, but no published media.

The gateway's eligibility predicate requires at least one published track, populated only when it sees RTP from the client. With no republished track the endpoint never became eligible again and every outbound call request was rejected with -32098 endpoint not eligible.

Observed in production on 2026-09-04: a deploy drain evicted 32 idle endpoints and 32 of 32 never became eligible again, some dead for 18 minutes. Reproduced in lab, where the post-eviction reconnect completes every gateway-driven step and the client-initiated offerSdp carrying the mic track never arrives.

This restores an unmerged fix (PR #15, closed 2026-08-24, absent from published 0.6.0/0.7.0/0.8.0) rebased onto current main, and closes three gaps in it.

Changes

• Replay on reconnect. republishStreams() re-attaches every retained stream to the new publishing peer connection and renegotiates once for all of them. Strict no-op on a first connect.
• Codec preferences survive the replay. PublishedStream now retains codecPreferences; previously the replay could only re-attach without them, silently changing negotiated codecs after a reconnect.
• Ended tracks are re-acquired. A track that ended while the socket was down (device unplugged, OS revoked the mic) can still be attached and produces a valid-looking SDP offer, but its sender never emits RTP - indistinguishable from never republishing. reacquireEndedTracks() re-acquires via getUserMedia using the retained constraints and swaps the fresh tracks into the same MediaStream, so the stream id and the object the application holds stay valid.
• DTMF senders are refreshed. localDtmfSenders is keyed by stream id and guarded with !has(id). Since the replay reuses the id, the guard short-circuited and the map kept the RTCDTMFSender from the closed peer connection, so sendDtmf after a reconnect went nowhere. The map is cleared before re-attaching.
• Failures reach the application. New onError callback. The SDK had no error channel at all (there is a standing // TODO: emit this as an error from an EventEmitter), and these failures happen on a signaling event where a throw becomes an unhandled rejection. Fires on republish failure and on a gateway handshake refusal. With no handler registered it logs, so existing applications are unaffected.

Signaling now also emits fatalError on the fatal-handshake path: during a reconnect the existing reject() targets a long-resolved promise, so the application was left holding a session that would never come back.

Test plan

• npm test - 86 passed, 86 total; prettier --check . clean; tsc --noEmit clean
• New coverage: no replay on first connect, replay on reconnect, exactly one renegotiation for three streams, codec preferences preserved, ended-track re-acquisition, no re-acquisition when live, derived constraints for an application-supplied stream, DTMF sender clearing, republish failure surfaced, re-acquisition failure surfaced, signaling fatalError emit
• On-device confirmation against a real gateway-initiated close

Notes

Part of a three-SDK change implemented to a shared contract; the Swift and Kotlin SDKs get the same semantics. All three keep the application's stream handle valid across a reconnect and expose the same onError shape.

🤖 Generated with Claude Code

[bwappsec]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.