A realtime speech pipeline tuned end to end for Korean conversation — turn-taking that waits through a backchannel, barge-in that tells an interruption from a nod, and graceful degradation instead of a dropped call.
A Silero voice-activity stop with backchannel handling, so a listener's 네 or 음 doesn't get treated as the end of your turn.
PII redaction, output guardrails, risk scoring, diarization, and Korean text normalization run together in a single pass over the stream.
Greetings are pre-synthesized at startup, and Korean filler audio covers a tool call that runs long, so the line never goes silent.
Time-to-first-audio and time-to-first-byte are measured per call, for running the system day to day — we don't publish them as benchmarks.
One call
Turn-taking, normalization, and guardrails tuned for Korean end to end — not an English pipeline with a translation layer bolted on.
Explore the pipeline30+
custom voice-pipeline processors
repository audit, August 2026
A call connects over WebRTC in the browser or Daily on mobile — both live today. Telephony-ready architecture is built and key-gated.
Greetings are pre-synthesized at startup, and Korean filler audio steps in when a tool call runs long — the wait is engineered away.
A Silero voice-activity stop, patient turn-taking, and Korean backchannel handling so the agent waits instead of talking over people.
Feature flags let the pipeline step down a capability when something is uncertain — risky paths default off, and the system holds the call instead of ending it.
A Silero voice-activity stop with backchannel handling, so a listener's 네 or 음 doesn't get treated as the end of your turn.
Korean-first turn detection waits for the caller to finish instead of clipping them mid-sentence.
See turn handlingTurn timeline
A backchannel does not hand over the turn; a barge-in stops the agent immediately.
Greetings are pre-synthesized at startup, and Korean filler audio steps in when a tool call runs long. Silence mid-call reads as a fault to the person on the line, so that gap is never left open.
See the observation pointsCall timeline
Filler only covers the stretch where a tool call runs long, and hands back the moment the response is ready.
Pipeline explorer
One call passes through these stages in order. For each one: what it does, what it leaves behind, and whether it is our own code or a vendor model we orchestrate.
Choose a stage
Processing order
We rent the models and build the conversation. Vendor models are orchestrated; the Korean tuning, the orchestration, and the reliability layer are ours in code.
What to show
A call connects over WebRTC in the browser or Daily on mobile. Telephony-ready architecture is built and key-gated.
Who built it
Our orchestration layer
Korean-first turn detection waits for the caller to finish instead of clipping them mid-sentence.
Turn-taking · realtime voice pipeline
Live transports
Browser voice over WebRTC and mobile voice run in production. The same pipeline handles both paths, so the transport changes but the conversation handling does not.
Browser
WebRTC, no install
Mobile
iOS and Android apps
Choose a transport
How a call starts on the selected transport. Browser (WebRTC)
Key-gated transports
The telephony architecture is built but key-gated — it is integrated per deployment, and we would rather say that plainly than imply you can dial in tomorrow.
Key-gated
Scoped per deployment
Stated plainly
A status per transport
The same pipeline shows up differently in the browser, on mobile, in the operator console, and on the call record. Wherever you start, the processing order is the same.
Consumer surface
Browser calling
Start a WebRTC call in the browser with nothing to install.
See the apps
Operations surface
Operator console
Handle call records and follow-up from a single screen.
See the console
Operations surface
Call record
Transcript and observation points remain after the call ends.
See the platformScoped in the deployment
Every engagement is scoped and priced per deployment rather than by a fixed plan or a per-credit meter. We start from your use case, expected volume, and integration surface, then quote a pilot and a path to production.
Counted in the repository
These are not marketing metrics. Each figure was counted in the repository, and describes how much we built — never performance or adoption.
30+
custom voice-pipeline processors
running together in a single pass over the stream
100+
feature flags
staging how capability is opened
450+
operator-console components
where the work after the call happens
34
care and consumer backend domain modules
the data flow schedules, records and notifications travel
Every figure was counted in the repository — audit, August 2026.
So you can retrace where the conversation crossed.
Per-call observability
Time-to-first-audio and time-to-first-byte are measured per call, for running the system day to day — we don't publish them as benchmarks.
See safety and reliabilityCall observation points
Signals this call leaves
Turn boundaries
Recorded
Barge-in points
Recorded
Failover events
None
The pipeline degrades instead of dropping — a vendor hiccup doesn't mean a dead call.
Sticky failover · silence watchdogs · health-gated deploys
Reliable by design
A voice call is unforgiving — the failure modes are handled ahead of time, not hoped away.
Feature flags let the pipeline step down a capability when something is uncertain — risky paths default off, and the system holds the call instead of ending it.
We orchestrate best-of-breed vendor models for speech-to-text, language, and text-to-speech. What we build is the Korean tuning, the orchestration, and the reliability layer around them — including sticky failover between TTS providers.
100+
feature flags staging how capability is opened
repository audit, August 2026
PII redaction, output guardrails, risk scoring, diarization, and Korean text normalization run together in a single pass over the stream. Data handling for a given deployment, including retention, is scoped with you during the engagement.
PII redaction
Personal data is redacted before it reaches the call record.
Output guardrails
Guardrails apply alongside the response, and risky paths default off.
Capability descriptions reflect the production pipeline. Transport availability varies by deployment — telephony is integrated during an engagement. We do not publish latency benchmarks; per-call timings are instrumented for operations.
Read the docsTime-to-first-audio and response latency captured on every call for our own operations, not published as benchmarks.
Per-call observability · not a public benchmark
An orchestration layer we own
Turn detection, barge-in, latency handling, and observation points are ours in code. We rent the models; we build the conversation. Below is how that configuration is shaped.
# Call session pipeline — the order is identical across transports.pipeline = Pipeline([ transport.input(), stt, # a vendor model we orchestrate korean_turn_tuning, # a processor we wrote guardrails, # PII redaction + output guardrails llm, # a vendor model we orchestrate tts, # sticky failover between providers transport.output(),])Browser, mobile, and the key-gated telephony path all run the same pipeline configuration. The transport changes; the processing order does not.
Read the guidesIn short
The transport opens, speech becomes text, Korean turn tuning decides whether the turn ended, and the response becomes sound again. Observation points attach across all of it.
A transport opens in the browser or on mobile and the call begins.
Speech is transcribed live, with Korean normalization right behind it.
Turn tuning separates an ending from a backchannel or a barge-in.
The response is synthesized; record and follow-up hand off to the console.
Book a walkthrough of the pipeline behind WelVoice — turn-taking, reliability, and telephony-ready transports.