DEV Community: Maxwell Lin

Telehealth video visits with expiring links: one API call per appointment

Maxwell Lin — Tue, 27 Oct 2026 07:29:15 +0000

From the Streaming CDN team. The original, kept up to date, is at streaming-cdn.ewin888.com/guides/telehealth-video-visit-api-expiring-links.

A clinic or health platform usually wants the same thing for every appointment: a link the patient can open in a browser without installing anything, a different link for the clinician, both dead after the visit window, and a record of when the visit really started and ended. On Streaming CDN that is one server API call per appointment. This guide walks through it with curl and a webhook handler.

1. Create the visit from your backend

Use a server API key with the temporary-meetings:write scope. Keep the key on your server; the browser only ever receives the links.

curl -X POST https://streaming-cdn.ewin888.com/v1/applications/temporary-meetings \
  -H "Authorization: Bearer scdn_your_server_key" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Follow-up visit",
    "guestDisplayName": "Patient",
    "staffDisplayName": "Dr. Lee",
    "mode": "face_to_face",
    "recordingEnabled": false,
    "expiresInMinutes": 60,
    "callbackUrl": "https://clinic.example.com/webhooks/visit",
    "metadata": { "appointmentId": "apt_4821" }
  }'

Field	Values	Notes
`title`	1–120 characters	Shown to your staff, not to the patient
`guestDisplayName` / `staffDisplayName`	1–90 characters	Defaults `Guest` and `Staff`; a second join on the same link gets a numeric suffix
`mode`	`face_to_face` or `observe_guest`	`observe_guest` starts the staff side with camera and microphone off
`recordingEnabled`	`true` / `false`	Records automatically when the visit begins. Default `false`
`expiresInMinutes`	5–1440	Validity of both links. Default 30
`callbackUrl`	Public HTTPS URL	Receives signed lifecycle events. Omit it to poll instead
`metadata`	JSON object	Your own ids, returned unchanged in queries and webhooks

The response contains two links and, when you passed callbackUrl, a secret that is shown only this once:

{
  "meeting": {
    "id": "temporary_meeting_...",
    "mode": "face_to_face",
    "status": "active",
    "joinCount": 0,
    "expiresAt": "2026-10-12T10:00:00.000Z"
  },
  "guestUrl": "https://.../temporary-meeting/tm_guest_...",
  "staffUrl": "https://.../temporary-meeting/tm_staff_...",
  "callbackSecret": "tmsec_store_this_once"
}

2. Send each link to the right person

guestUrl goes to the patient, by SMS, email or your patient portal. It opens a browser page with camera and microphone; there is no app to install.
staffUrl stays inside your clinician tools. It joins with the host role, so never send it to a patient.
The links are bearer tokens: anyone holding one can join until it expires. Store meeting.id, not the URLs, in your appointment record.

3. Expiry, rotation and revocation

Need	Call	Result
Patient lost the link, or it was sent to the wrong address	`POST /v1/applications/temporary-meetings/{id}/links/guest`	A new guest link; the old one stops working immediately
Replace the clinician link	`POST /v1/applications/temporary-meetings/{id}/links/staff`	Same, for the staff link
Appointment cancelled	`DELETE /v1/applications/temporary-meetings/{id}`	The room ends and both links are revoked
Check where a visit stands	`GET /v1/applications/temporary-meetings/{id}`	Status, expiry, join count, start and end times

A visit moves through active → in_use → completed, or ends as expired or revoked. Opening a link after the visit has expired, ended or been revoked returns 410 temporary_meeting_unavailable, and rotating a link on a finished visit returns 409; show the patient a "this visit link is no longer valid" page and, if appropriate, create a new visit.

4. Know when the visit really happened

The visit counts as started only when at least one patient and one clinician are online together, so a patient waiting alone does not start the clock. Your callbackUrl receives temporary_meeting.started and then temporary_meeting.ended with startedAt, endedAt, durationSeconds, endReason, participantPeak and your metadata. Each event has a stable id; use it to ignore duplicates.

Verify every webhook before trusting it. The signature is an HMAC-SHA256 of timestamp + "." + rawBody with the callbackSecret, base64url-encoded:

import { createHmac, timingSafeEqual } from "node:crypto";

export async function handleVisitWebhook(request: Request, callbackSecret: string) {
  const rawBody = await request.text();
  const timestamp = request.headers.get("x-streaming-cdn-timestamp") ?? "";
  const supplied = request.headers.get("x-streaming-cdn-signature") ?? "";
  const expected = "v1=" + createHmac("sha256", callbackSecret).update(`${timestamp}.${rawBody}`).digest("base64url");
  const ok = supplied.length === expected.length && timingSafeEqual(Buffer.from(supplied), Buffer.from(expected));
  if (!ok || Math.abs(Date.now() / 1000 - Number(timestamp)) > 300) {
    return new Response("invalid signature", { status: 401 });
  }
  const event = JSON.parse(rawBody);
  // event.type: "temporary_meeting.started" | "temporary_meeting.ended"
  // event.metadata.appointmentId identifies your appointment
  return new Response("ok");
}

Answer with any 2xx status. Failed deliveries are retried, so the handler should be idempotent on the event id.

5. Recording, when you need it

With recordingEnabled: true the visit is recorded from the moment it begins. Recordings are kept on the platform and can be listed with GET /v1/rtc/recordings?roomId=<meeting.roomId> and downloaded with GET /v1/rtc/recordings/{id}/download, using a server API key. Decide per appointment type whether to record; many visits should not be.

6. Optional: confirm a real person first

For visits where identity matters, create a liveness check with POST /v1/applications/liveness/sessions and send its verification link before the visit link. The patient follows on-screen actions (blink, shake the head, nod) in the browser and your backend receives a signed liveness.completed result; only then send guestUrl.

What stays with you

The platform provides the video, the links, the verification and the recording. Medical records, consent, what you record and how long you keep it remain the healthcare provider's responsibility under local regulations. Put only non-identifying ids such as an appointment id in title and metadata, not diagnoses or patient names.

Streaming CDN runs one-to-one video visits from your backend: separate patient and clinician links that expire, joined from a browser with no app. Learn more.

White-label live streaming for resellers: per-customer domains, isolation and usage billing

Maxwell Lin — Tue, 27 Oct 2026 07:27:06 +0000

From the Streaming CDN team. The original, kept up to date, is at streaming-cdn.ewin888.com/guides/white-label-live-streaming-reseller-domains.

A reseller, agency or group brand that runs live video for many customers needs each of them to look and behave like a separate service: their own domain in the player URL, their own stream names, their own protection rules, and a bill that matches what they actually used. This guide shows how Streaming CDN models that, and what the setup looks like for one new customer.

The model: one workspace per customer

Per customer	What it means
Workspace	Its own console login and settings; one customer never sees another's streams or numbers
Ingest domains	Where encoders publish, for example `push.customer-a.com`. Each ingest domain is its own stream namespace
Playback domains	Where viewers watch, for example `live.customer-a.com`. Each playback domain is bound to one ingest domain
Protection	Stream Keys, publisher IP allowlists, signed playback URLs, Referer/Origin allowlists and request-source policies, set per domain
Usage ledger	Traffic measured per customer, stream and domain, as the basis for billing

Stream names never collide

Every ingest domain is an independent namespace, so two customers can both publish a stream called main without touching each other. A customer with several ingest domains, for example one per event or per brand, gets one namespace per domain as well.

A playback domain plays the streams of the ingest domain it is bound to. Several playback domains can be bound to the same ingest domain, for example one per partner site, each with its own allowlist and policy, and a playback domain can be re-bound later without changing the encoder.

Customer A
  push.customer-a.com   (ingest)    ->  stream "main"
  live.customer-a.com   (playback, bound to push.customer-a.com)

Customer B
  push.customer-b.com   (ingest)    ->  stream "main"   (a different stream)
  watch.customer-b.com  (playback, bound to push.customer-b.com)

Domains on the customer's own DNS

Add the domain in the customer's workspace and choose ingest or playback (a playback domain also picks its ingest domain).
The console shows one CNAME record. The customer, or you on their behalf, creates it at their DNS provider.
The platform issues and renews the TLS certificate. The console shows the domain's DNS and certificate status, and the domain becomes usable only when both are active, so a half-configured domain never serves viewers.
Publish from OBS over WHIP to https://push.customer-a.com/live/main and watch at https://live.customer-a.com/live/main.

Browsers only allow camera and microphone on secure origins, which is one more reason the certificate has to be active before a domain is used for publishing from a web page.

Protection per customer

Because protection is set on each domain, a customer that embeds the player on one site can lock playback to that site's origin, while another customer that sells tickets can require signed playback URLs. Stream Keys are created per ingest domain and shown once; publisher IP allowlists stop anyone else from publishing into the customer's namespace.

Billing by actual usage

Usage is recorded per customer, per stream and per domain, so a customer's bill can be broken down the same way.
A reseller account sees all of its customers, opens new customer workspaces with just an email address, and gets a monthly statement of its customers' usage for settlement.
Customers under a reseller pay through the reseller, not by card on the platform, so the commercial relationship stays with you.
Request logs record every playback and publish and export as CSV, which helps answer a customer's "why is my bill higher this month".

Checklist for a new customer

Create the customer's workspace with their admin's email address.
Add an ingest domain and a playback domain bound to it; have the customer create the two CNAME records.
Wait until both domains show DNS and certificate active.
Turn on Stream Key authentication and create a key for the encoder; add the publisher's public IP if it is fixed.
Set the playback protection the customer needs: allowed origins, signed URLs, request-source policy (start in log mode).
Publish a test stream and confirm it plays on the customer's playback domain and appears in their usage.

Streaming CDN delivers live video to browsers over WebRTC, with chat and votes on real-time data channels, adaptive quality, recording and playback protection. Learn more.

WebRTC vs HLS for live streaming: latency, interaction and when to use each

Maxwell Lin — Wed, 07 Oct 2026 06:28:55 +0000

From the Streaming CDN team. The original, kept up to date, is at streaming-cdn.ewin888.com/guides/webrtc-vs-hls-live-streaming-latency.

HLS and DASH cut a live stream into segments of a few seconds and the player buffers several of them before it starts, so viewers usually watch several seconds or more behind the camera. Low-latency variants shrink that, but the design is still built on files and buffers. WebRTC sends media continuously as packets over a real-time connection, so end-to-end delay is measured in hundreds of milliseconds.

Side by side

	HLS / DASH	WebRTC
Typical delay	Several seconds and more	Low hundreds of milliseconds
How media travels	Segment files over HTTP, buffered	Continuous packets over a real-time connection
Browser playback	Through a player library (native in Safari)	Native in every modern browser
Interaction in the same moment	Viewers react to what happened seconds ago	Host and viewers interact in the same second
Weak networks	Switches renditions between segments	Simulcast: several quality levels at once, each viewer gets what their line can carry

When the seconds matter

Live chat, Q&A and votes: a host answering a question that is already ten seconds old breaks the conversation.
Live commerce and auctions: bids and flash-sale stock have to match the picture.
Sports and esports: with in-play predictions or bets, a viewer who is seconds behind learns the result from a faster source first.
Remote monitoring: operators watching vehicles, tables or sites need the picture as it is now.
Classes and coaching: a teacher's question and a student's answer must meet in real time.

When HLS is still fine

One-way broadcasts where nobody interacts, and on-demand video, do not gain much from shaving seconds; plain HTTP delivery and long caches work well there.

WebRTC delivery without building it

Running WebRTC at scale means media servers, TURN relays, simulcast, reconnects and a delivery network close to viewers. Streaming CDN does that part:

Publish from OBS over WHIP, RTMP or SRT encoders, or relay an existing RTSP, RTMP or HTTP-FLV stream.
Viewers watch over WebRTC in the browser, through a network in more than 130 countries and territories, with nothing to install.
Chat, votes and live data travel on real-time data channels in step with the picture.
Signed playback URLs, Referer/Origin allowlists and request-source policies keep the stream on your own pages.
Usage is measured per customer, stream and domain for billing.

Streaming CDN delivers live video to browsers over WebRTC, with chat and votes on real-time data channels, adaptive quality, recording and playback protection. Learn more.

Video calls in React Native and Expo that ring a locked phone: push wake-up, CallKit and full-screen Android calls

Maxwell Lin — Wed, 07 Oct 2026 06:28:34 +0000

From the Streaming CDN team. The original, kept up to date, is at streaming-cdn.ewin888.com/guides/react-native-incoming-call-screen.

A calling app has to ring when it is not running: on a locked iPhone, on an Android phone in a pocket, after the system has reclaimed the process. That takes a push that wakes the app and a system incoming-call screen, on each platform in its own way. This guide shows how the Streaming CDN calling SDK does it for React Native and Expo.

How a call reaches a sleeping phone

The caller starts a call; the call service sends a push with the call id, caller and mode (audio or video).
iOS: a VoIP push (PushKit) wakes the app, which reports the call to CallKit. Android: an FCM message wakes the app, which shows a full-screen incoming-call notification.
The person answers from the lock screen. The app accepts the call with its client token.
The service makes the accept atomic — the first device to answer wins — and returns the media credential to that device only. Every other device signed in as the same person stops ringing.

The push itself carries no media token and no server key; the media credential is returned only after the accept succeeds.

{
  "callId": "rtc_call_...",
  "callerId": "user-17",
  "callerName": "Alex",
  "mode": "video",
  "expiresAt": "2026-07-26T04:00:00Z"
}

Install

npm install @streaming-cdn/rtc-react-native react-native-webrtc

Bare React Native apps rebuild the native project as usual.
Expo apps need a development build or EAS Build (see the next section).
Upgrading from a version without the native call layer means rebuilding the native project; until then native calls report that the module is unavailable.

Expo: what changes

Install the SDK and the native WebRTC runtime with npx expo install @streaming-cdn/rtc-react-native react-native-webrtc (or npm).
Add "@streaming-cdn/rtc-react-native" to plugins in app.json / app.config.js; the plugin writes the camera and microphone usage descriptions.
Run npx expo prebuild, then make a development build (eas build --profile development, or npx expo run:ios / npx expo run:android). Expo Go cannot load a native WebRTC runtime, so calls do not work there.
Test push wake-up on a real device: the iOS simulator does not receive VoIP pushes, and the Android full-screen permission below should be checked on the phones your users actually have.

{
  "expo": {
    "plugins": ["@streaming-cdn/rtc-react-native"]
  }
}

Register each device for push wake-up

Your backend issues a client token per signed-in user and device. The deviceId must identify the installation, never the person: the service tells the answering user's other devices to stop ringing by comparing device ids.
Register the device for managed push only if you want the service to wake the app: iOS registers its PushKit VoIP token (64 hex characters), Android registers its FCM token. A registration whose platform does not match the client token is refused with 400 push_token_platform_mismatch instead of being stored and failing silently later.
Tokens the push provider later reports as invalid are marked and skipped on the next call.
Already have your own push or WebSocket channel? Deliver the incoming-call payload through it and hand it to the SDK; managed push is optional.

Join a call

Your backend keeps the server API key and hands the app a short-lived credential:

import { ReactNativeRtcClient } from "@streaming-cdn/rtc-react-native";

const identity = await fetch("https://your-backend.example.com/api/rtc/identity", {
  credentials: "include"
}).then((response) => response.json());

const rtc = new ReactNativeRtcClient({
  credential: identity.credential,
  mode: "video",
  publishAudio: true,
  publishVideo: true,
  receiveAudio: true,
  receiveVideo: true
});
await rtc.join();

What the native call layer gives you

Capability	API	Platform behaviour
Locked-screen and background calls	`RtcNativeIncomingCalls`	Android full-screen intent notification; iOS PushKit with CallKit
Ringtone and ringback	`RtcCallTones`	Honours the Android ringer mode; on iOS CallKit owns the incoming ringtone
Audio output routing	`client.setAudioOutput()`, `RtcAudioRouting`	Earpiece, speaker and Bluetooth through Android `AudioManager` and iOS `AVAudioSession`

On iOS a call identifier must be a UUID. On Android your app owns its Firebase registration and forwards payloads to the SDK, so Firebase stays an optional dependency.

The Android 14 trap: full-screen intent

USE_FULL_SCREEN_INTENT is what lets an incoming call take over the screen. Three facts to know before shipping:

Since Android 14 (API 34) it is a special app access, granted automatically only to apps whose core function is alarms or calls. Other apps start without it.
Since 31 May 2024, Google Play requires a declaration for it in the Play Console (App content → Sensitive permissions). Submit it before review.
When the grant is missing there is no error: the call silently becomes an ordinary heads-up notification that is easy to miss. A build can pass testing and still be effectively uncallable on real devices.

Check at runtime and guide the user before the first call:

const caps = await RtcNativeIncomingCalls.getIncomingCallCapabilities();
// caps.presentation: "full-screen" | "notification" | "none"
if (caps.presentation !== "full-screen") {
  // explain why, then:
  await RtcNativeIncomingCalls.openFullScreenIntentSettings();
}

getIncomingCallCapabilities() also reports notificationsEnabled; when it is false the call will not appear at all. On iOS the result is always full-screen, because CallKit owns presentation.

Ringing ends on its own

A ringing invitation is valid for 45 seconds and a call nobody answers is closed as missed. On Android the incoming-call notification also carries a system timeout (45 seconds by default, ringTimeoutMs in the push payload, 10–120 seconds), so ringing stops even if the app process was reclaimed and no cancel can run.

Errors worth handling

Response	Meaning	What to do
`401`	The client identity token expired	Refresh it through your backend
`403`	This identity is not a recipient of the call	Do not show the call
`409`	Another device answered, or the call stopped ringing	End the incoming UI quietly
Push after `expiresAt`	The call is over	Discard it without showing any UI

The Streaming CDN calling SDK brings voice and video calls with system incoming-call screens to iOS, Android, Web, React Native and Expo. Learn more.

Go live from OBS to the browser in under a second with WHIP

Maxwell Lin — Wed, 07 Oct 2026 06:28:12 +0000

From the Streaming CDN team. The original, kept up to date, is at streaming-cdn.ewin888.com/guides/obs-whip-webrtc-live-streaming.

WHIP (WebRTC-HTTP Ingestion Protocol) lets an encoder publish over WebRTC with a single HTTP request. OBS Studio supports it natively, so a stream can go from OBS to viewers' browsers over WebRTC end to end, in the low hundreds of milliseconds, instead of the several seconds that segment-based delivery such as HLS adds.

1. The publish URL

OBS publishes to your ingest domain, a publish point and a stream name:

https://<ingest-hostname>/<publish-point>/<stream-name>

# example
https://push.example.com/live/camera-01

The publish point defaults to /live; the value configured in the console is authoritative.
The stream name is the last path segment and is case-sensitive. Streams published at the same time on one ingest domain need different names.
Viewers watch through a playback domain bound to the ingest domain the stream was published to.

2. Before you publish

The ingest domain has active DNS and TLS.
If source IP allowlisting is on, add the publisher's public egress IP (a private LAN address is not enough).
If Stream Key authentication is on, create a key for this exact ingest domain. The secret is shown once.
Use a current OBS Studio release that includes WHIP.

3. OBS settings

Open Settings → Stream and enter:

OBS field	Value
Service	`WHIP`
Server	The full WHIP URL, including publish point and stream name
Bearer Token	The ingest domain's Stream Key (empty only when Stream Key authentication is off)

OBS sends the Bearer Token as Authorization: Bearer <stream-key>. Treat Stream Keys as passwords: never put them in public URLs, screenshots, repositories or shared OBS profiles.

4. Recommended output for low latency

Setting	Value	Why
Video encoder	H.264 (hardware or software)	Broad browser support
Rate control	CBR	Predictable bandwidth
720p bitrate	1.5–2.5 Mbps	Adjust for motion and source quality
1080p bitrate	3–6 Mbps	Adjust for motion and source quality
Keyframe interval	1 second	Faster first frame and recovery
H.264 profile	Main or Baseline	Avoids unsupported decoder features
B-frames	0	Lower latency
Audio	Enabled, not muted	WHIP negotiates the audio track

5. Check that it works

OBS changes from Connecting to Live.
The console's Live streams list shows the stream name with active tracks.
Open https://<playback-hostname>/<publish-point>/<stream-name> and check video and audio.

6. When it does not work

Symptom	Likely cause	What to do
`401 invalid_stream_key`	Missing, expired, revoked or wrong-domain key	Create a key for the active ingest domain and paste it into Bearer Token
`403 publisher_ip_denied`	The publisher's public IP is not allowed	Add the real public egress IP, or turn the allowlist off while testing
`429 Too Many Requests`	A duplicate publisher, or a concurrency limit	Stop the old publisher or use a different stream name
OBS stays on Connecting	Firewall, outbound UDP/DTLS, DNS or TLS	Check DNS/TLS, allow outbound UDP, read the OBS log
Live with no picture	Hidden or muted source, incompatible output	Check the OBS preview and mixer; use H.264 and a one-second keyframe interval

Publishing from a web page instead

A browser page can publish too: WHIP with fetch() and a send-only RTCPeerConnection. Because that request is cross-origin, list the page's origin under the ingest domain's browser publishing origins (CORS) in the console. Encoders such as OBS never ask for CORS and are unaffected.

Streaming CDN delivers live video to browsers over WebRTC, with chat and votes on real-time data channels, adaptive quality, recording and playback protection. Learn more.

How to stop other sites from re-streaming your live video

Maxwell Lin — Wed, 07 Oct 2026 06:27:41 +0000

From the Streaming CDN team. The original, kept up to date, is at streaming-cdn.ewin888.com/guides/stop-live-stream-hotlinking.

Once a live stream's URL is public, anyone can embed it on their own site, or run a scraper in a data center that re-streams it, and you pay for the traffic. No single setting stops every case; the answer is layers, each cheap to apply and each closing a different gap.

1. Signed playback URLs

Your backend signs the playback URL with an expiry. A copied link stops working once it expires, so a URL pasted into a forum or another site is only good for a short time. Signed URLs only control who can start playback; a viewer who is already watching is not cut off.

2. Referer and Origin allowlists

List the pages allowed to embed the player. Requests from any other site's page are refused, which stops the most common case: someone embedding your player or stream on their own page.

3. Request-source policies

Real viewers come from home and mobile networks; most re-streaming scrapers run in data centers. A request-source policy classifies each request by the network it comes from and lets you log or refuse data-center sources per playback domain. Start in log mode, look at what it would have refused, then turn on refusal.

4. Address blocking

When a specific source keeps pulling your stream, block its addresses. Request logs record every playback and publish, and can be exported as CSV to find the source.

5. Protect ingest too

Protection is not only for viewers. Require a Stream Key on each ingest domain, and allowlist the publishers' public IP addresses where they are fixed, so nobody can publish into your channel.

What not to do

Do not cap how many times or how long legitimate viewers may watch to fight abuse: that turns away the audience you are paying to reach. Use the layers above, which target the abusers, not the viewers.

On Streaming CDN

Every customer sets these on its own playback and ingest domains in the console: signed URLs, Referer/Origin allowlists, request-source policies, address blocking, Stream Keys and publisher IP allowlists.

Streaming CDN delivers live video to browsers over WebRTC, with chat and votes on real-time data channels, adaptive quality, recording and playback protection. Learn more.