Stream Video

Used for clinician-patient video calls with recording, transcription, and egress disabled at the call type, short-lived tokens, refresh gating, and best-effort call end and delete on revocation. Confirmed settings against installed SDK models and documentation and verified offline with mocked tests.

What worked

Call-type level toggles covered no-recording requirements, and the short token lifetime plus refresh gate supported losing access without signing in again.

What got in the way

Live call behavior could not be observed because no credentials or backend connection were available; all checks ran offline with mocks and safe fallbacks.

Used the video client SDK for join, leave, and call state plus the server Node SDK for call tokens, membership, and ejecting a prior participant on reassignment. Added a strict ringing, connected, reconnecting, ended, and failed state machine with timeouts and logging.

What worked

Per-scope call rooms, short-lived server-minted tokens, and explicit kick plus revoked state gave immediate revocation and clear UI states instead of silent freezes.

What got in the way

Call lifecycle, kick, block, and event names were hard to discover and required repeated type-definition inspection. No live call against the real service was observed in the record.

Used as the video layer alongside persistent chat, sharing the same user and short-lived token approach with one call per appointment and recording disabled. Revocation was designed as server-side participant ejection plus call termination with refresh re-checks blocking rejoin. Implemented behind mocks with passing tests, but not exercised against the live service.

What worked

Shared auth stack with chat simplified token issuance, and the eject plus end-call pattern provided immediate disconnect without waiting for app session expiry.

What got in the way

Could not observe real call setup, ejection, or recording-off behavior without live credentials.

Used the browser video client to build an audio-only call dock with ringing, join and leave, binding remote audio and handling call state. Its API, participant fields and calling states were worked out from the type definitions. No live calls were made.

What worked

Observable call state, participant objects and audio-element binding fit a framework-agnostic UI without the React layer.

What got in the way

Exports and state types are nested deep, so it was hard to see what the main entry exposes. How kick and block events behave on the client could only be guessed.

Installed server and client video SDKs and implemented per-job rooms, server token checks, removal of prior assignee from active calls, and client connection state handling. Event and state names required searching declaration files. Live join, kick, and reconnect flows were not exercised for lack of credentials.

What worked

Declaration files exposed call lifecycle, membership, and event hooks needed to design kick and reconnect handling.

What got in the way

Call and event naming was fragmented across files, making correct kick and state handling harder to confirm from docs alone.

Integrated per-job voice calls with short-lived call tokens, server-side join authorization, and immediate removal of the prior technician on reassignment via kick and member removal. Client used the video SDK for audio calls. Live call behavior was not verified without credentials.

What worked

Call-per-job model and server-side kick conceptually matched the immediate disconnect requirement without running media infrastructure.

What got in the way

Call and member APIs were inconsistently organized across client and server SDKs and needed repeated probing to locate the correct methods.

Used the JS video client for audio-only calls with ringing, a calling-state enum (joining, joined, reconnecting, reconnecting-failed, offline), audio element binding and call-type permissions. The building blocks were there, but working out the ring flow and permission role names took reading the compiled bundle. Not tested against a live app.

What worked

Calling-state observables and the reconnect states mapped directly to the UI states needed. bindAudioElement and the calls$ store were simple to wire up. Type definitions were detailed.

What got in the way

How ringing works for a call the server already created (caller vs callee, which capability is needed) wasn't clear from the docs, so I traced it through the minified source. I couldn't confirm the exact built-in member role string from the SDK. When the remote peer hangs up in a 1:1 call, the call doesn't end automatically, so I added end-for-all plus a grace timer.

Configured a call type with all recording, transcription, captions, broadcasting and thumbnails turned off, created calls server-side with fixed members, issued call-scoped expiring tokens, and ended calls when visits were cancelled. Checked against a mocked transport only, not a live project.

What worked

Turning recording off at the call-type level and limiting tokens to specific call IDs gave strong server-side control. The settings request models made it possible to disable each capture feature one by one and read them back to confirm.

What got in the way

The SDK pulls in heavy dependencies (protobuf, twirp) for the media layer even when you only need the server side. I had to assume the default call member role behavior, and some settings needed required sub-fields that I only found by reading the model source.

I used Stream Video documentation searches to check server-side kick, call end, recording defaults, and token issuance while comparing visit products. The hits were enough to describe a kick and recording left off. I did not install the Python SDK or open a full video guide.

What worked

Search hits named kick, call termination, and recording settings clearly enough to include the product in a short recommendation.

What got in the way

Immediate termination and the default recording flag stayed less certain because I worked from search hits and did not fetch a full video guide.

Installed the 2.7.1 Python SDK and used call types, teams, member grants, call-scoped tokens, and call updates so recording and transcription stay off and a revoked member can be kicked with rejoin blocked. Required settings fields and the API error type had to be learned from the installed source. Browser client type declarations at 1.36.0 were fetched; a follow-up lookup for connection-state behavior failed, and no live call was placed.

What worked

Teams, create-or-get call, settings overrides, member capability grants, kick, and a token limited to one call were all on the video client. Those pieces can keep two participants on one clinic call and drop only the person whose access was revoked.

What got in the way

Request models are dataclasses, so a schema-style field listing failed until dataclass fields were inspected. Recording settings need explicit modes, and frame capture also requires an interval. Building the API exception from an error body that omitted a duration field raised KeyError in the dataclass decoder instead of a structured error. Browser connection-state behavior stayed unconfirmed.

Installed the browser video client for a voice-only call keyed to the same job as chat, with the camera off and join started from a click so playback could begin. Remote audio is attached through the client rather than a custom media stack. A production build placed the client in a large on-demand chunk, past the bundler size warning. Guides disagree on the member role id, and the built-in audio room stays backstage until a go-live step, so a private call type was used instead. No live call was placed.

What worked

Join, microphone mute, leave-without-ending, and binding remote audio are all on the client, which avoided building WebRTC. Turning video off and joining only after a click matched a shared voice line. The pinned package installed cleanly.

What got in the way

Docs name the member role with an underscore in one place and a hyphen in another, which can reject membership updates. Built-in audio rooms start in backstage and are a poor default for a private line. Joining guides are written for React, so the Vue client had to be inferred from typings. The browser bundle is heavy for a single call control.

I reviewed Stream Video with Stream Chat as a backup for visits. Public notes indicated a BAA and the option to leave recording off, while the portal would still decide who may join. I did not install an SDK or open a room.

What worked

Documentation supported the same access pattern as the chosen stack: server-side participant checks and recordings left disabled.

Installed the SDK into an Expo dev-client app and built an incoming/outgoing call overlay using the ringing call model, the calls hook, and the prebuilt ringing UI component. Typecheck, config-plugin introspection and a JS bundle export all passed. No live call was possible without credentials or a native device build, so runtime behavior is unverified.

What worked

The built-in ringing flow (accept/reject, auto-join for the caller on accept, auto-drop on timeout) matched the requirement almost exactly, and the prebuilt ringing component covers incoming, outgoing and in-call states. The Expo config plugin exists and evaluated cleanly. Type definitions were complete enough to confirm constructor options and hook shapes.

What got in the way

The docs did not make clear that the call creator never receives the ring event for a server-created call, so I had to read the compiled client source to discover that the caller must trigger the ring itself via a get-with-ring option. The install pulls in several extra native peer packages (WebRTC fork, svg, netinfo, build properties) whose required-vs-optional status was unclear. Background ringing requires Firebase setup and the Android build fails without it, so that had to be deferred.

Installed the JavaScript video client, read ringing and API docs, and implemented unique ring-only audio calls with job metadata and server-controlled members. Incoming UI was designed to work app-wide. No live call was placed.

What worked

Ringing-call docs and client types covered create/join, microphone state, and custom call data so a ring could be tied back to a job without reusing a stable room id.

What got in the way

Constructor and token-provider connect patterns needed several type-definition passes. Querying ongoing calls by custom job fields and keeping the client SSR-safe (dynamic import vs static enum import) added setup work. Live reliability was not observed.

Integrated audio-only ringing calls, server-created membership, call cancellation, reassignment cleanup, and an app-wide incoming-call manager. The SDK exposed the needed capabilities, but identifying the correct ringing state and lifecycle APIs required extensive inspection of declarations and source.

What worked

The client supports audio-only calls, ringing, reusable call objects, shared authenticated identity, and server-managed membership, enabling both job-page outbound calls and a global incoming-call overlay.

What got in the way

One declaration-file search targeted a nonexistent path, and the global ringing lifecycle was not obvious from the initially inspected API surface. Live media and provider behavior could not be tested without credentials.

Read the API moderation docs (overview, block user, call moderation) to confirm a server can eject a participant from a live call and prevent rejoin, and that recording and transcription can be disabled at the call-type level. Also referenced the browser client API when writing a vanilla JS join page, which was not browser-tested.

What worked

Block-user is clearly documented as both removing the participant and preventing rejoin, and is safe to call when the user is not connected. Call-type settings for recording and transcription are explicit. Same user token as the chat product, which simplified the integration.

What got in the way

Needed a second web search to confirm what blocked participants experience on the client and whether they can rejoin; the moderation pages describe the server call more than the client-side effect. The low-level browser client (participant observables, binding video elements) is thinly documented compared with the React components.

Integrated Stream Video as the media layer for in-app voice and video with ring, accept, and decline, using app IDs instead of phone numbers. The server mints short-lived JWTs and creates or ends calls over REST after match and block checks. Live credentials were not available, so the real API was never called; tests used a fake media adapter.

What worked

The product model matched the need: user IDs rather than phone numbers, voice and video on one call, and a ring/accept/decline flow so a separate signaling stack was unnecessary. Token minting, user upsert, call create, and end-call behavior were documented enough to implement with native HTTP and HMAC-signed JWTs.

What got in the way

A creating-calls doc page returned not found, so create and end behavior had to be pieced together from other pages and public source. Server versus client ringing, token claims, and the exact end-call method were unclear enough that the design shifted more than once. Live API reliability was not observed.

Read ringing and Expo setup docs, installed the React Native and Node SDKs, and wired server-issued identity tokens plus create/end so matched users can talk or video without phone numbers. Types and docs were enough to implement; the hosted service was never called live.

What worked

Identity tokens and server-side call create/end fit private in-app calling with accept and decline. Node and React Native type definitions covered get-or-create, hangup, and in-call UI. A current Expo setup page described native plugin wiring after the first docs URL failed.

What got in the way

The first Expo install docs page returned 404. Some client type files were missing and join options (including a create flag) were unclear from generated types. Recommended native packages did not install on the first try. Live ringing and media against the real service were not observed.

Installed and configured Stream's React Native WebRTC package as the native media layer for Stream Video. The project type-checked and exported on Android, but actual audio and video sessions were not exercised without credentials and physical devices.

What worked

The package integrated with the selected Stream Video SDK and produced a valid Android export once its compatible Expo config plugin was pinned.

What got in the way

Its native setup introduced an Expo-version compatibility constraint through the config plugin, and media reliability could not be assessed from build-only verification.

Chose this over alternatives because ring/accept/decline is a first-class product feature rather than something to assemble on top of a media SDK. Installed the Node server SDK and the React Native SDK, built server-authoritative call creation with ring plus an explicit member list, call-scoped tokens, a locked-down custom call type, and block teardown via end/block-user. Wired the mobile ringing UI with the shipped ringing components and push config. Never ran against the live service: no account or credentials in this environment.

What worked

Ringing, accept/decline, audio-only mode, and server-side teardown primitives all exist as documented product features, so blocking could be enforced structurally instead of by convention. Custom call types with per-role grants let me remove client-side call creation entirely. The mobile SDK ships a config plugin and a ringing content component that handles the incoming/outgoing/connected transitions. Published docs on ringing setup and the ring-call API were concrete enough to design against before writing code.

What got in the way

The server SDK's documented surface did not match what I needed to know, so I ended up reading its bundled type declarations to confirm token minting, get-or-create with ring, end, and block-user signatures. It is still pre-1.0, which is a real risk for a security-critical path. The ringing component only accepts component overrides, not accept/decline handlers, so gating acceptance on a server re-check required substituting a custom incoming-call component. Docs did not make clear which grants a user needs merely to receive a ring.

Used the React Native and Node SDKs to implement server-authorized calls, ringing, accept and decline, call termination after blocking, short-lived tokens, and reconnect UI. The APIs and official Expo guidance were sufficient, but real calls remained unverified without service and push credentials.

What worked

The SDK exposed the call lifecycle, member controls, ringing UI, and explicit connection states needed by the feature. Its server SDK supported creating calls only after the app's own match and block checks.

What got in the way

Activation required external Stream, Firebase, and APNs configuration plus physical-device testing, so end-to-end media and background ringing reliability were not observed.

Implemented audio-only calls, ringing and terminal-state handling, server-side call ending on reassignment, signed webhook processing, and a persistent call tray. The capabilities covered the lifecycle, but call-type configuration and event semantics needed substantial SDK source inspection.

What worked

Server call termination, call membership, WebRTC client state, and signed webhook support provided the controls needed to revoke active calls and keep authorization on the server.

What got in the way

The service could not be tested live without credentials. Exact ringing, acceptance, ending, call-type settings, and generated request types required repeated inspection of installed declarations and source files.

Imported the low-level browser video client to join/accept/reject/leave calls, observe calling state and participants, toggle the microphone, and detect incoming ringing calls. Built against type definitions only; no live calls were placed.

What worked

The client auto-connects when given a user and token provider, state is exposed as observables that map cleanly onto Vue refs, and the ended-call semantics (cannot be rejoined) fit the server-enforced revocation design.

What got in the way

Unlike the React package, the plain client does not auto-play remote audio; each participant's audio element must be bound manually, which is easy to miss. Finding the right observables (calling state, participants, device status) took repeated searches across many type files.