DEV Community: Maxwell Lin

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.

Native incoming calls in React Native: CallKit on iOS, full-screen calls on Android

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 expo prebuild and a development build or EAS Build — Expo Go cannot load a native WebRTC runtime. Add @streaming-cdn/rtc-react-native to the Expo plugins list so the camera and microphone usage descriptions are generated.
Upgrading from a version without the native call layer means rebuilding the native project; until then native calls report that the module is unavailable.

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.