Feature/inbound stream notification#13
Open
smoghe-bw wants to merge 18 commits into
Open
Conversation
…call flow onStreamAvailable now fires twice: first with callId (WS notification, no mediaStream) for call-arrival UI, then with mediaStream (WebRTC ontrack) for audio setup. Guard both handlers so audio setup only runs on the second fire. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
- App.tsx owns all stream event registration (single onStreamAvailable handler); routes WS notification (callId only) to incoming call banner, routes WebRTC ontrack (mediaStream) to MediaPlayer for audio setup - Incoming call banner with Accept/Decline buttons appears on streamAvailable WS notification; accept calls acceptStream(callId), decline calls declineStream(callId) - MediaPlayer simplified: accepts inboundStream prop, wires audio via useEffect instead of relying on the stream callback directly Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
npm link symlinks are not followed by react-scripts' bundled TypeScript. A file: reference causes npm install to copy the built dist/ directly into node_modules so CRA resolves types correctly. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
…l state The subscribe peer's WebRTC ontrack fires on initial connection before any call exists. callExpectedRef is set only when the WS streamAvailable notification arrives, ensuring the MediaStream and inCall state are only set when a real call is active. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
…cation arrives WebRTC ontrack fires once at connection setup, before the WS streamAvailable notification. Store the stream in subscribeStreamRef regardless of call state; wire it to inboundStream when the notification arrives (or on explicit accept) so the audio visualization always receives the stream. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
- Remove setInboundStream from WS notification path; audio only wires up
on explicit accept, preventing the stream from playing before the user
answers
- CallController.handleHangUp now calls setInCall(false) directly after
hangupConnection resolves instead of waiting for streamUnavailable; the
gateway also returns {status} not {result} so dropped the stale field read
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
hangupConnection set inCall=false but left inboundStream populated, so MediaPlayer kept rendering the remote audio visualization after call end. A useEffect on inCall ensures the stream is cleared for all exit paths. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
ontrack fires once per WS session lifetime — the subscribe peer's MediaStream is permanent. Clearing it on streamUnavailable left subscribeStreamRef null for the second call, so accept had no stream to wire up. callExpectedRef still gates when the stream is used. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
When inboundStream becomes null the audio element's srcObject was left pointing at the old MediaStream so the browser kept playing buffered audio from the ended call. Clear it explicitly in the cleanup path. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
The SDK may call onStreamAvailable twice when the new gateway SSRC mapping is in use: once from the signaling WS notification (no mediaStream) and once from the WebRTC ontrack event (with mediaStream). Guard against null mediaStream by returning early rather than throwing so the second call (which carries the real stream) can proceed normally. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
…eam together) The updated SDK (metadata-for-stream-events) now fires onStreamAvailable once with both callId and mediaStream set, correlating the WS notification and WebRTC ontrack internally. The previous handler only covered two cases: WS-only (callId, no stream) and ontrack-only (stream, no callId), so the combined event fell through without setting inboundStream. Add an explicit combined-event branch that handles accept/decline/autoAccept the same way as the split paths, while keeping the old two-phase and ontrack-only branches for backwards compat with older SDK versions. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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
1 participant
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.