The browser gives you NAT traversal, mandatory encryption, packet loss recovery, jitter buffering, congestion control and a set of production codecs. For free, standardised, maintained by people who do nothing else.
That is genuinely the hard computer science, and it is already solved.
Then you build on it, and discover that the hard computer science was not the expensive part. What follows is the itemised list of what remains — and the observation that only one item on it has anything to do with video.
WebRTC SDK vs build — what the browser already hands you
Worth being precise about the starting position, because it is substantial. The W3C WebRTC specification defines an API surface that includes ICE candidate gathering and connectivity checking, the DTLS handshake and SRTP keying, RTP packetisation and RTCP feedback, retransmission and keyframe requests, jitter buffering, bandwidth estimation, and encoder and decoder implementations for several codecs.
That is most of everything the browser already runs between two tabs, and reimplementing any of it would be a serious project on its own. Nobody sensible does.
So the question is never whether to build WebRTC. It is what to build around it, and that turns out to be a much longer list than the first list.
What a video SDK is actually selling you
Here is the reframe that makes the decision tractable: a video SDK is not a video library. The video is in the browser already.
What an SDK sells is failure handling. Connections that do not establish, connections that break and come back, devices that disappear mid-call, browsers that behave differently from each other, networks that degrade, and a way to find out what went wrong afterwards. Strip those out and the remaining surface — get a camera, send it somewhere, display what arrives — is genuinely an afternoon.
This is the level of detail that the strategic comparison of WebRTC and proprietary SDKs deliberately stays above. That piece frames the decision in terms of cost, timeline, control and compliance, which is the right frame for choosing. This one goes underneath it and names the actual code, because the development effort is systematically underestimated when nobody itemises it.
The WebRTC SDK vs build inventory: nine things you own
Everything below is yours with raw browser APIs. Roughly in the order you encounter it.
1. Signalling, identity and rooms
The specification defines the session description format and deliberately says nothing about transporting it. So you build the channel — usually WebSocket — plus reconnection for the signalling channel itself, message ordering, authentication, who is allowed into which room, who is allowed to publish, and the state that tells a joining participant what already exists.
This is typically the largest single piece and it is entirely undifferentiated. Every video product has built the same thing.
2. The ICE lifecycle
Establishing a connection is handled for you. Everything around the edges of that is not.
You watch connection state transitions and decide what each one means for your application. Disconnected is not failed — it often recovers on its own, and treating it as fatal produces calls that drop unnecessarily. Failed usually needs an ICE restart, which means generating a fresh offer with new credentials and getting it to the far end through signalling that may itself be reconnecting.
You also decide the timeouts, the retry policy, and what the user sees during each of it. And because it fails silently on corporate networks, you need a diagnosis path that distinguishes a transient blip from a network that will never allow a connection at all.
3. Renegotiation
A call is not static. Someone starts screen sharing, turns a camera on, switches to a different microphone, or a track ends. Each of these fires a negotiationneeded event and requires a fresh offer/answer exchange while media is flowing.
The hazard is concurrency. Two participants can trigger renegotiation simultaneously, producing a glare condition where both sides are offering at once. Handling that correctly — perfect negotiation, with a designated polite peer that rolls back — is a well-defined pattern and it is not obvious, and getting it wrong produces intermittent failures that only appear when two people act at the same moment.
4. Device management
Enumerate available cameras and microphones, handle the permission prompt and every way a user can refuse it, cope with device labels being hidden until permission is granted, detect a device being plugged in or removed mid-call, and switch tracks without tearing down the connection.
None of this is conceptually hard. All of it is a long tail of cases that each need code and a UI state, and it is where a surprising share of real bug reports originate.
5. Browser and platform differences
Autoplay policies that block audio until a user gesture. Mobile browsers suspending video tracks when a tab backgrounds. iOS Safari's particular constraints around when and how a stream can be attached to an element. Differences in which constraints are honoured and which are silently ignored.
This is the least glamorous item on the list and the one that never finishes, because it changes with browser releases rather than with your roadmap.
6. Relay infrastructure
The browser will use a TURN server. It will not provide one. You deploy relay infrastructure, placed and credentialled, issue short-lived credentials per session rather than embedding static ones in client code, keep certificates current for the TLS fallback, and size capacity for a relay rate that depends on your users' networks rather than your traffic.
7. The quality experience
Congestion control is handled. What the user is told about it is not. The estimator downgrades and says nothing, so you decide what a degraded participant looks like, whether to show a connection indicator, what happens visually when someone's video freezes versus when they turn it off, and how to distinguish those two states — which look identical and mean completely different things.
8. Observability
The statistics API exposes a large volume of per-connection data. Collecting it, shipping it somewhere, correlating both ends of a session, and turning it into an answer to "why was this specific call bad" is entirely your problem.
Teams routinely defer this and then cannot diagnose anything, because a WebRTC failure that was not instrumented at the time is essentially unrecoverable after the fact.
9. More than two participants
Everything above assumes two peers. Past that, each participant sending to every other participant exceeds what client uplink and CPU can sustain by around the fourth or fifth person, and a media server stops being optional. That is not an addition to the list — it is a second system, with its own deployment, scaling behaviour, failure modes and bill.
Count the items. One of them — the ninth, and only partly — is about moving video. The other eight are about the conditions under which moving video stops working.
The one that is always underestimated
If a team is going to run out of budget on one item, it is reconnection.
It gets estimated as a retry and it is a state machine. A real call has to survive a laptop sleeping and waking, a phone switching from wifi to cellular mid-sentence, a tunnel, a VPN reconnecting, and a signalling server being redeployed underneath it. Each of those produces a different combination of states across the peer connection, the signalling channel and your application, and they can occur in any order and simultaneously.
It is also nearly impossible to test properly. Simulating a network transition faithfully requires either real devices moving through real conditions or fairly elaborate network emulation, and the bugs are timing-dependent, which means they are intermittent, which means they are expensive to reproduce.
The symptom in the field is characteristic: a product that demos flawlessly and accumulates complaints about calls that dropped for no clear reason. Those calls did have a reason. It just was not instrumented, which is item eight failing at the same time.
Which of these should you actually own?
The useful split is not build versus buy, it is which items differentiate you.
Two items are genuinely yours: what users see when conditions degrade, and what you learn from sessions that went badly. Both are product decisions wearing infrastructure clothing, and outsourcing them produces something indistinguishable from every competitor using the same vendor.
The other seven are identical in every video product ever shipped, appear in no pitch deck, and consume most of the calendar.
When building is genuinely right
The honest counterweight, because the list above reads as an argument against building and there are real cases where it is wrong.
- Video is the product, not a feature of it. If real-time media is your core differentiation, owning the stack is the point and the list above is your engineering roadmap rather than your overhead.
- You need behaviour no vendor offers. Custom congestion control, an unusual codec pipeline, deterministic behaviour for a regulated environment, or an architecture no SDK anticipated.
- Deployment constraints rule out the alternatives. An air-gapped network, a jurisdiction no provider operates in, or hardware nobody supports.
- You already have the expertise. A team that has shipped WebRTC before will move through this list several times faster than the estimates suggest, because most of the cost is discovery rather than typing.
Outside those cases, building the seven undifferentiated items is spending a quarter on work that is identical to what a competitor bought, and that no customer will ever notice you did yourself.
Build, Buy, or Deploy
Three routes, with the honest boundary on each.
Build on open source
mediasoup, Janus, Pion and LiveKit give you the server side; the browser gives you the client primitives. You write all nine items. This is the right call when video is the product or when constraints rule out everything else, and it means the long tail — item five in particular — becomes a permanent line in your maintenance budget rather than a one-off project.
Buy a cloud video API
Per-minute providers hand you all nine, which is a genuine acceleration and the fastest path to shipping. The limits are that you inherit their behaviour on the two items that should be yours — the degradation experience and the diagnostics — and you generally cannot see per-session statistics in enough detail to answer why one specific call was bad.
Deploy a commercial platform
The middle path runs a commercial platform on infrastructure you choose. Samvyo is one such option: based on SFU architecture, shipping embeddable SDKs, with the media path, TURN and recording kept on infrastructure you control. The relevant part for this decision is that the seven undifferentiated items arrive solved while deployment, relay placement and data path stay yours — and the two items worth owning remain in your application, where they belong. It is resilient by design rather than something you assemble.
Where it does not fit: if you need to modify behaviour at the protocol level, build. And for a two-party feature that will never need a media server, the browser plus a modest amount of signalling is genuinely sufficient and an SDK is overhead.
The Bottom Line
The browser solves the hard computer science — NAT traversal, encryption, loss recovery, congestion control, codecs — and hands it over for nothing. What remains is nine items of application engineering, and eight of them are about failure rather than video.
A video SDK is a failure-handling library with a camera API attached. Decide accordingly: buy the seven items that are identical in every video product, own the two that users actually experience — what they see when quality drops, and what you learn when a call goes wrong. And whatever you decide, budget reconnection properly, because it is a state machine that every team estimates as a retry.
What's Next
For the same decision expressed as a schedule rather than a code inventory, what this costs in calendar time turns these items into a scope table you can plan against. And for what the browser is actually doing underneath all nine, everything the browser already runs between two tabs walks the full pipeline.
Frequently Asked Questions
What does a video SDK actually do that raw WebRTC doesn't?
Failure handling, mostly. The browser already provides NAT traversal, encryption, loss recovery, jitter buffering, congestion control and codecs. An SDK provides signalling, room and identity management, reconnection and ICE restart, renegotiation, device handling, browser quirk compatibility, relay infrastructure, diagnostics, and a media server for group calls. Only the last is really about moving video.
Is it hard to build video calling with raw WebRTC?
A two-person call is genuinely straightforward — the browser does the difficult parts. Production is hard for different reasons: nine categories of application code around the media, of which reconnection, renegotiation and browser-specific behaviour are the ones that consume the most time and are hardest to test.
What is the most underestimated part of building on WebRTC?
Reconnection. Teams estimate it as a retry and it is a state machine spanning the peer connection, the signalling channel and application state, which must survive sleep, network switches, tunnels and server redeploys in any order. It is also very hard to test faithfully, so the bugs are intermittent and expensive to reproduce.
Do I need a TURN server if I use raw WebRTC?
Yes. The browser will use a TURN server when a direct path is unavailable, but it does not provide one. You deploy relays, place them near users, issue short-lived credentials per session rather than embedding static ones in client code, and maintain certificates for the TLS fallback.
What parts of a video feature should I build myself?
The two that users experience: what happens visually when quality degrades or a call interrupts, and the diagnostics that tell you why a session went badly. Those are product decisions. Signalling, reconnection, renegotiation, browser quirks, relay infrastructure and the media server are identical in every video product and appear in no pitch deck.
When is building on raw WebRTC the right choice?
When real-time video is your product rather than a feature of it, when you need behaviour no vendor offers, when deployment constraints rule out the alternatives, or when you already have a team that has shipped WebRTC before. Outside those cases you are spending a quarter on work a competitor bought.
Can I keep control of the infrastructure without writing all of this?
Yes — that is the middle option. A platform deployed on infrastructure you choose, such as Samvyo, hands you the undifferentiated engineering while the media path, TURN placement and recording stay under your control. The parts worth owning remain in your application.
