WIGTN CREW
WIGVO Real-Time Phone Call Interpretation
Bridges a web client and any phone number with two real-time voice sessions. The receiving side just answers the phone, with no app and no carrier integration.
Accepted to ACL 2026- Role
- Relay server and deployment infrastructure · Paper co-author (1 of 5)
- Period
- 2026
- Stack
- FastAPIPython 3.12OpenAI Realtime APITwilio Media StreamsDockerCaddy
Outcome
555ms
Median caller-to-callee latency (measured in production)
0
Echo-induced translation loops across 147 calls
$0.28
Cost per minute of call time
01What it is
An open-source system that interprets between two languages in both directions, in real time, over regular phone network calls. It connects a web client and an arbitrary phone number through two concurrent voice sessions, using a telephony API's media streams for transport. The receiving side needs no app install and no carrier integration. It was accepted to the ACL 2026 System Demonstrations track and is released under the MIT license.
02The problem to solve
Bidirectional interpretation over the phone network creates a failure mode of its own: an echo loop, where the interpreted audio plays out of the other party's speaker, comes back in through the microphone, and gets translated again. Once it starts, the same phrase repeats until the call ends. On top of that, the phone network has narrow bandwidth and is latency-sensitive, so common echo cancellation techniques are hard to apply as-is.
03Alternatives considered
How to break the echo loop determined the identity of the system. The paper compared three approaches.
| Option | Strengths | Drawbacks |
|---|---|---|
| Acoustic echo cancellation (AEC) | The standard technique in call quality, with many existing implementations | The phone network's narrow band and high latency jitter make reference signal alignment difficult, and it cannot remove enough of the leaked interpretation audio |
| A single session handling both directions | Half the session cost and a simpler setup | Cannot tell whether the audio it hears is the other party speaking or the interpretation it just sent out, so it cannot prevent a loop of re-translating its own output |
| Dual sessions + echo gatingChosen | Separates sessions by direction and decides whose turn it is to speak, cutting off the very path by which its own output comes back | Requires managing the state and cost of two sessions, and the relay server becomes the real-time bottleneck |
04My part
I was responsible for the relay server and the deployment infrastructure. The relay server sits between the two voice sessions and the telephony API's media streams, relaying audio and actually enforcing the echo gating. Because it must not stall or lag while a call is running in real time, most of the work was about managing resources and lifecycles precisely rather than adding features.
- Managed concurrent call capacity under a single lock, guaranteeing that reserved plus active calls never exceed the cap
- Structured the call lifecycle of reserve, confirm, and terminate so that calls failing during setup never linger holding resources
- Built the real-time path, including audio routing, ring buffers, voice activity detection, and barge-in handling
- Added a recovery path for dropped sessions and filtering for hallucinated responses
- Cleaned up the server entry points, including request rate limiting and tenant auth key issuance
- Attached an observability layer that tracks latency and event loop lag, so mid-call bottlenecks can be examined after the fact
- Built the Docker Compose and Caddy based deployment setup and operated it with automatic certificate renewal
05Results
The paper's core contribution, dual-session echo gating, uses deterministic silence injection and energy-based voice activity detection to decide whose turn it is to speak, blocking the path by which the system's own output comes back. In the production deployment it recorded a median caller-to-callee latency of 555 milliseconds, 0 echo loops across 147 calls, and $0.28 per minute of call time, evaluated over 155 Korean-English calls, and the supported languages are not limited to that pair. The relay server is verified by 47 test files covering unit, component, integration, and load tests.