WebRTC Rescue — When Your Live Video Is Failing and Nobody Can Say Why.
Trembit is a WebRTC rescue team that takes over failing real-time video and voice products: calls that drop, connections stuck on “connecting”, audio that goes one way, rooms that freeze past a handful of participants, code a previous vendor left behind. We find the failing layer (signaling, ICE/TURN, DTLS, codec negotiation or the media server), fix it there, and tell you plainly when fixing isn’t worth it.
Trusted by Product Teams Worldwide
In Brief
Trembit is a WebRTC engineering company that rescues failing video and voice platforms. A rescue starts with a Rescue Assessment (two weeks): we instrument the live system, trace the failure to a protocol layer, load-test to the concurrency you need, and hand you a prioritized remediation plan with a clear recommendation to fix, partly rebuild, or stop. Stabilization then runs in two-week sprints (critical fixes first, then production monitoring and a documented handover) with 2–4 engineers plus a tech lead who talks directly to your CTO. Cost drivers are how many layers are failing, client platforms (web, iOS, Android), media server and hosting, compliance constraints (HIPAA, GDPR, KBV) and whether documentation exists; the firm estimate comes with the assessment.
Signs Your WebRTC Product Needs a Rescue
Calls work on office Wi-Fi and fail on mobile data, hotel networks or corporate VPNs.
That pattern almost never means an application bug. It usually means the connection can’t find a network path: TURN credentials are wrong or expired, a relay port is blocked, or the app only exchanges direct candidates when a relay is required.
Both sides say "connected", and there is no picture or sound.
Signaling completed, so nobody sees an error. The cause sits one layer down: ICE candidates sent before the remote description was applied and silently dropped, or an offer and answer with no codec in common, such as an H.264-only mobile client talking to a VP8-only server.
It's fine with two people and freezes at ten.
Calls connect, then degrade as the room grows: frozen video, CPU spikes, a participant ceiling nobody planned for. That is media-server territory: simulcast layers the client never sends, forwarding rules, bandwidth estimation, or a recorder starving the media threads.
It works in Chrome and breaks in Safari, or on iPhones.
Browser and device differences shift with every release: SDP format mismatches, media constraints Safari silently ignores, iOS audio and background-tab behavior. Without a compatibility matrix built from real traffic, each release is a gamble.
Three patches later, the drop rate hasn't moved.
Retry logic, reconnect banners and SDK upgrades treat symptoms one layer above the failure. If nobody can show you connection-state and getStats() data from production, nobody can tell whether any patch is helping.
The team that built it is gone, and a compliance audit or big contract is coming.
An agency that delivered and left, a founding engineer who moved on, a vendor who “finished” the project. No documentation, every fix is a guess, and the cost of the next failure has just gone up.
| What you see | Layer it usually lives in | What we check first |
|---|---|---|
| Fails on mobile / LTE / VPN, works on Wi-Fi | ICE / TURN | Is TURN configured, reachable and issuing valid credentials? Is any candidate pair succeeding? |
| “Connected” but no media | Signaling / SDP | Are ICE candidates queued until the remote description is set? Do offer and answer share a codec? |
| ICE succeeds, then the call times out | DTLS | Does the a=fingerprint in the SDP match the certificate? Is a middlebox dropping DTLS? |
| One-way audio or a frozen frame | Codec / media tracks | Are bytesSent and bytesReceived both incrementing? Is simulcast actually being sent? |
| Degrades as participants join | Media server | Forwarding rules, simulcast layer selection, bandwidth estimation (REMB vs TWCC), TURN parity with clients |
| Works in Chrome, broken in Safari | Client / browser | SDP format, getUserMedia constraints, iOS audio and background behavior |
| “It randomly fails” | No observability | Connection-state logging and getStats() in production, before anything else |
Deeper reading: How to rescue a broken WebRTC codebase: the protocol-level diagnosis playbook · Why WebRTC projects fail: 5 common problems in production
The Rescue Assessment: What You Get in Two Weeks
A rescue should not start with a rewrite, or with a sprint you pay for before anyone knows what’s wrong. The Rescue Assessment is a fixed-scope first step. We instrument before we change anything, trace the failure to a layer with evidence, and hand you four artefacts. You decide what happens next with those in hand.
Root-cause diagnosis at the protocol level
A written diagnosis that names the failing layer or layers (signaling, SDP and codec negotiation, ICE/TURN, DTLS, the SFU or media server, the client and network) and the top contributing causes, each backed by evidence: SDP captures, candidate-pair dumps, DTLS state, getStats() traces.
Load test at the concurrency that matters to you
We reproduce the failure under the load your business actually runs, whether that’s 40 people in a class, 20 in a group session or a spike at launch. Then we record where quality breaks and why.
Prioritized remediation plan
Every fix listed in order of impact, with the layer it touches, the risk of changing it, and a rough effort class. Critical stability fixes come first, and structural changes are sequenced behind them so the live product keeps working while it’s repaired.
A clear recommendation: fix, partial rebuild, or stop
One explicit call, with the reasoning. Fix in place, rebuild only the media layer and keep your application layer, or stop investing in this codebase. If the honest answer is “don’t spend more on this,” the report says so.
The assessment diagnoses and plans; it doesn’t fix. If you want a standalone architecture review or infrastructure audit of a product that works but underperforms, that’s WebRTC consulting.
Assessment report outline
- Symptoms as reported vs symptoms as measured
- System map: signaling, TURN/STUN, media server, clients, hosting
- Findings by layer, with evidence
- Load-test results and the break point
- Remediation plan, prioritized
- Recommendation: fix / partial rebuild / stop, with rationale
- Observability gaps and what to instrument
Not sure which layer is failing?
Send us the symptoms — dropped calls, one-way audio, rooms that freeze past a handful of participants — and an engineer will tell you which layer to look at first. Typical response time: under 24 hours.
Fix, Rebuild, or Go Back to the Original Vendor?
Once the root cause is known, there are four realistic paths. None is right by default. Here’s how we weigh them with you.
| Fix in place | Targeted rebuild (media layer only) | Full rebuild | Go back to the original vendor or hire in-house | |
|---|---|---|---|---|
| Right when | Failures trace to a few layers and the architecture fits your scale | The media layer (signaling, TURN, SFU) is unsound but the application layer and UI are worth keeping | Architecture, code quality and documentation are all beyond repair, or the product has changed direction | The vendor is still reachable, knows the code, and the problem is features or capacity, not protocol-level failure |
| Main risk | Hidden problems surface as fixes land, which is why fixes follow the evidence and the plan’s order | Integration seams between old application code and the new media layer | Longest time with the old, failing system still in production; scope creep | The team that couldn’t find the root cause is asked to find it again |
| What you keep | Almost everything | Application logic, UI, user data, integrations | Product knowledge and data, little code | Continuity with the people who wrote the code |
| What the assessment gives you | The fix list, in order | The boundary: what to keep, what to replace | Confirmation that rebuilding is necessary, not just tempting | The diagnosis, which any team can act on |
Our default is to keep what works. A rebuild is a recommendation we make with evidence, not a starting assumption.
How a Rescue Runs
Technical call (30 minutes, free)
You describe the symptoms; an engineer asks where signaling, TURN and the media server sit. You leave with a first read on which layer is failing, whether or not you go further.
Rescue Assessment (two weeks)
Instrumentation first, then diagnosis, load test, remediation plan and recommendation. No fix work is billed as a sprint before you have the report.
Stabilize at the failing layer
Critical fixes deploy first, in two-week sprints with working builds on staging. Fixes go in where the failure lives: ICE/TURN configuration, negotiation logic, certificate handling, codec policy, forwarding rules. They don’t go one layer up where patching is easier.
Prove it held in production
Connection success, call drop rate and quality metrics tracked from getStats() on real traffic, so the improvement is measured rather than asserted. The same monitoring catches the next problem early.
Document, hand over, or stay
We write the documentation the original team didn’t: signaling flow, TURN setup, media-server configuration, codec policy, the failure modes we fixed. Then we transfer knowledge to your team, or stay on as your engineering team.
What We Need From You
A rescue moves as fast as access does. To start the assessment we need three things:
Codebase access
Read access to the repositories that matter: web and mobile clients, signaling server, media-server configuration, and infrastructure-as-code if you have it.
Current infrastructure docs
Whatever exists: architecture diagrams, hosting and TURN details, vendor accounts. “There are no docs” is a common answer, and not a blocker.
2 hours with your engineering lead
Spread across the two weeks: a walkthrough at the start, questions as we trace the failure, and the findings review at the end.
Helpful, not required: examples of failing calls (time, device, network); access to production logs, or permission to add telemetry; a staging environment we can load-test against; an NDA in place before you share anything.
Rescues We've Delivered
Two different rescues, because not every stalled product has the same problem.
Meetaway: inherited video code that multiple teams couldn't fix
Meetaway came to us with semi-functional video code built on WebRTC and TokBox, after several earlier teams had tried and failed. We took it over and got it working.
“They know the inner workings of the tech and were able to inherit our semi-functional code and get it to work where multiple prior teams couldn’t.”
— Whitney Kramer, Founder, Meetaway (via Clutch)
Learnster: rescue isn't always the code
Learnster, a Swedish corporate learning platform, had stalled under a previous engineering team. The diagnosis was process and communication, not code. We transferred the project in one week, started with a three-engineer core team and grew it to 11 over two years. Seven-plus years later we still run its engineering.
Why that second story is on a WebRTC page: a failing video product sometimes has a delivery problem in a protocol problem’s clothes. The assessment looks at both, and says which one you have.
Compliance proof (not a rescue): when a fix must survive a regulator, it helps that the same team built a KBV-certified psychotherapy video platform in Germany.
What Our Clients Say
“Trembit has deep expertise and experience in WebRTC and Tokbox. They know the inner workings of the tech and were able to inherit our semi-functional code and get it to work where multiple prior teams couldn’t. It was a tough project and yet they breezed through it — we’d highly recommend them to anyone looking to build video tech.
“Their proactive team gets things done as if it were their own project, consistently delivering high-quality outputs.
Why Teams Call Trembit When Their Video Is Failing
-
We instrument before we rewrite
The first days of a rescue go into telemetry and connection-state logging, not code changes. Fixes then target a measured failure instead of a hunch.
-
We'll tell you when to stop
Some codebases aren’t worth saving. The assessment ends with an explicit fix, partial rebuild or stop recommendation, and we put it in writing even when the answer costs us the engagement.
-
WebRTC is all we do
We’re one of roughly 50 companies worldwide focused exclusively on WebRTC, working on real-time communication since 2009. Signaling, TURN, DTLS and SFU failures are our daily work, not an escalation.
-
We stay after the fix
Rescues often turn into long partnerships. Our longest-running client relationship began as a takeover and has run for seven years, and clients typically stay 1–3+ years.
Frequently Asked Questions
Is your video failing right now?
Tell us what users are seeing and what’s already been tried. An engineer will get back to you with a first read on where the failure probably lives, and what a Rescue Assessment would cover.
Part of our WebRTC development practice. Need a review rather than a rescue? See WebRTC consulting.