VAPI-3507 stream available and unavailable events#5
Merged
Conversation
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
added 3 commits
April 27, 2026 10:29
Emit connectStatus event separately from ready so callers can subscribe to connect status updates independently via onConnectStatus.
smoghe-bw
changed the title
This was referenced Apr 27, 2026
…reamAvailable callback - RtcStream.mediaStream and callId are now optional: notification fires first with callId (no mediaStream) for call-arrival UI, then again via WebRTC ontrack with mediaStream when audio flows - signaling.ts subscribes to streamAvailable/streamUnavailable WS events and emits them for BandwidthRtc to forward to the app's handler - Adds acceptStream(callId?) and declineStream(callId?) on BandwidthRtc and Signaling so apps can explicitly accept or decline an inbound stream - Non-null assertions on setMicEnabled/setCameraEnabled/unpublish callers that always pass publish()-originated streams Co-Authored-By: Claude Sonnet 4.6 (1M context) <[email protected]>
Delegates to v1 BandwidthRtcV1. Co-Authored-By: Claude Sonnet 4.6 (1M context) <[email protected]>
Without an explicit types entry, CRA's compiler couldn't resolve declaration files from the dist/ directory via the npm link symlink. Co-Authored-By: Claude Sonnet 4.6 (1M context) <[email protected]>
…consumers When installed via file: reference, CRA's source-map-loader follows relative paths in .js.map files that escape the project root through the symlink, causing ENOENT. Disabling source maps removes the .map files entirely. Co-Authored-By: Claude Sonnet 4.6 (1M context) <[email protected]>
Backwards compatibility shim: if the app never calls onStreamAvailable, the gateway's new closed-gate-between-calls behavior would silently break audio on all calls after the first. Auto-accepting keeps existing apps working without any code change on their side. Apps that register onStreamAvailable get the new ring/accept UX and are responsible for calling acceptStream explicitly. Co-Authored-By: Claude Sonnet 4.6 (1M context) <[email protected]>
Gateway now opens the EgressGate at streamAvailable send time, so old SDKs that never call acceptStream are unaffected. The SDK-side shim is no longer needed. Co-Authored-By: Claude Sonnet 4.6 (1M context) <[email protected]>
Dead code from before the peerType-based offerSdp was adopted. Co-Authored-By: Claude Sonnet 4.6 (1M context) <[email protected]>
smoghe-bw
changed the title
Build was blocked by a prettier check on the tsconfig. No logic changes; prettier --write reformatted the file so npm run build can proceed. Co-Authored-By: Claude Sonnet 4.6 (1M context) <[email protected]>
…rences Defaults to true. When true the gateway immediately re-opens the egress gate after each call ends, so the next call's audio flows without any round-trip delay. Pass false to restore legacy behaviour (gate stays closed until streamAvailable is processed by the gateway). Co-Authored-By: Claude Sonnet 4.6 (1M context) <[email protected]>
…mNotification callback Previously the signaling-layer streamAvailable WS event was routed through onStreamAvailable, which fires before the WebRTC ontrack event arrives and therefore has no mediaStream. This broke existing consumers who assume onStreamAvailable always carries a populated mediaStream. Introduce onInboundStreamNotification as the dedicated callback for the pre-media gateway notification (carries callId/autoAccepted, no mediaStream). onStreamAvailable continues to fire only from the WebRTC ontrack handler, so mediaStream is always present and existing consumers are unaffected. Co-Authored-By: Claude Sonnet 4.6 (1M context) <[email protected]>
…undStreamNotification callback" This reverts commit e587b4d.
…ble single event Previously the SDK fired onStreamAvailable twice per call: once from the WebRTC ontrack event (with mediaStream only) and once from the WS streamAvailable notification (with callId/autoAccepted but no mediaStream). This broke existing apps that expected a single event with mediaStream always set. Now the SDK holds the subscribe MediaStream from ontrack internally and only fires onStreamAvailable once the WS notification arrives, delivering a combined event with mediaStream, callId, and autoAccepted all present. ontrack ordering is handled in both directions (stream arrives before or after the WS notification). onStreamUnavailable is similarly fired from the WS streamUnavailable notification using the stored stream, with onremovetrack as a fallback for older gateways. A callIsActive guard prevents double-firing when both fire. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
…anges Keep both: WS streamAvailable/streamUnavailable correlation handlers and acceptStream/declineStream from this branch, plus retryIceOnFailed from main. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
smoghe-bw
changed the title
The gateway now negotiates a fresh subscribe track per call (unique msid) and sends WS streamAvailable/streamUnavailable per call, instead of one persistent track negotiated at connect. The correlation logic assumed ontrack fired once at connect, which broke across consecutive calls: - pendingSubscribeStream was never cleared at call end, so a later call whose WS streamAvailable arrived before its ontrack fired onStreamAvailable with the stale previous-call stream. Clear it on both call-end paths. - The WS streamAvailable handler didn't check callIsActive, so if the onunmute fallback already fired, WS fired onStreamAvailable a second time. Guard it. - onremovetrack leaked streamTracks entries when WS streamUnavailable fired first (per-call streams accumulate). Always delete the entry; fire only if the WS path hasn't. onStreamAvailable/onStreamUnavailable now fire exactly once per call with callId/autoAccepted metadata, and the onunmute/onremovetrack fallbacks still cover gateways that don't send the WS events. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
…s accept/decline BREAKING CHANGE: inbound stream handling is reworked; intended as the 1.0.0 cutover. The gateway no longer sends separate streamAvailable/streamUnavailable RPCs. It rides caller identity (from/fromType/autoAccepted/tags) on the subscribe sdpOffer that adds a call's per-call track, keyed by track id, and the SDK derives stream available/unavailable from the offer's m-section changes (ontrack / onremovetrack). - types: SubscribeSdpOffer.trackMetadata (was streamSourceMetadata) keyed by trackId; add TrackMetadata; RtcStream gains from/fromType/tags and drops the internal callId. - signaling/core: drop the streamAvailable/streamUnavailable WS listeners and the WS/ontrack correlation machinery; stash trackMetadata from handleSubscribeSdpOffer and attach it to onStreamAvailable via track-id lookup on ontrack. - accept/decline are first-class again: with autoAccept off the gateway parks the call (egress gate closed, ringing) and the app prompts, then acceptStream opens the gate (audio flows) or declineStream cancels the call. No callId args — the gateway acts on the current per-call track. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
… metadata-for-stream-events
smoghe-bw
changed the title
dhelms-bw
approved these changes
Jul 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.