🎯 TL;DR

<aside> 🌐 한국어 버전 → 딸깍 한 번에 전화번호가 생기고, 그 전화가 디스코드로 울린다

</aside>

• The moment a phone number stops being a carrier contract and becomes a software asset spun up with a single API call on a developer-first CPaaS (Vonage), voice calls turn from telco paperwork into code.

• When a call comes in, we steer it with an NCCO (JSON), fork the call audio over a WebSocket, and pull it into a channel on the world's #1 gaming voice platform, Discord, where an agent answers with a single "Answer call" button — we follow the entire path in real .NET code.

• And honestly: why this voice path is not yet built on actors, while the chat fan-out in the very same codebase is Akka.NET actors. Where does "one call = one actor" lead at scale? The Luware case study shows the destination.

🎨 Figure 1 — Hero: the journey from a one-click phone number to a Discord call

Who is this for

This is for developers who work on voice calls (phone support), and for business owners wondering "we'd love to add phone support, but where do we even start?" Setting our own product aside for a moment, we dig — at the code level — into the engineering issues of a journey that runs phone-number creation → inbound call → agent routing → all the way to Discord, the #1 gaming voice platform using the **Akka.NET actor model** and the Vonage Voice API on .NET.

There's a single thesis: telephony and the actor model aren't strangers — they were born from the same body. We trace that root first, then descend into the actual implementation.

Part 1. Why the actor model — telephony's DNA

The actor model isn't a buzzword. It began in 1973 with Carl Hewitt, Peter Bishop, and Richard Steiger's IJCAI paper "A Universal Modular Actor Formalism for Artificial Intelligence." The rules fit in three lines:

• Everything is an actor. On receiving a message, an actor can ① compute, ② create new actors, and ③ send messages to other actors (or itself).
• An actor holds its own private state and processes messages from its mailbox one at a time.
• No shared memory → no locks, and race conditions disappear structurally.

The stage where this model actually changed the world was the telephone. Erlang was born in 1986 at Ericsson for telephone switches. The process model of the language, led by Joe Armstrong, was the actor paradigm — and it's where the famous "Let it crash" philosophy comes from.

Don't try to defend against every failure with defensive code. Let a broken process just die, and let a supervisor restart it to a known-good state. The blast radius of a failure stays confined to a single call.

Ericsson's Erlang-based AXD301 switch is widely cited as achieving extreme availability (the oft-quoted "nine nines / 99.9999999%" figure traces back to Joe Armstrong's PhD thesis and is interpreted differently depending on measurement conditions, so treat it as a symbol, not a spec). The point isn't the number — it's the design: one call = one isolated process (actor) was not a metaphor but how real switches actually ran.