What Happens When You Press the Call Button

You tap a name on your phone. A few seconds later, their phone rings. They answer, and you are talking. It feels instant, simple, almost magical.

It is not simple. Between your finger hitting glass and their ear hearing your voice, an extraordinary chain of events takes place. Dozens of systems coordinate across thousands of miles in fractions of a second. Hardware, software, protocols, and physics all working together so seamlessly that you never think about any of it.

Until it does not work. Then you are stuck with choppy audio, weird delays, or calls that drop for no apparent reason, and you have no mental model for what might be going wrong.

This post gives you that mental model. We are going to follow a VoIP call from the very first moment to the very last, step by step, in plain language. No protocol diagrams. No packet headers. Just what is actually happening and why it matters.

Step 1: Your phone figures out who to call

When you tap a contact, your phone does not actually know how to reach that person yet. It knows a phone number (or a SIP address, if you are using a softphone), but it needs to figure out where to send the call.

Your phone or VoIP app connects to your VoIP provider's server. Think of this server as a switchboard operator. Your phone says: "I want to talk to this number." The server says: "Let me figure out where that number lives and set things up."

This initial handshake is called signaling. It is a conversation between your device and the server about the call itself, not the audio. They negotiate the details: what audio format to use, where to send the voice data, what capabilities each side supports.

If the other person uses the same VoIP provider, the server already knows where their phone is. If they are on a different provider or a traditional phone line, the server has to route the request through the broader telephone network. Either way, it figures out the path and tells the other phone to start ringing.

This all happens in about one to three seconds. Most of that time is not computation. It is the signals physically traveling between servers, sometimes across continents.

Step 2: The other phone rings

Once the signaling path is established, the remote phone rings. Or vibrates. Or lights up with a notification. Whatever the receiving device is configured to do.

Here is something people do not realize: the ringing you hear on your end is not the actual ring of the other phone. Your VoIP provider generates a fake ringback tone and plays it to you while it waits for the other side to answer. The other phone might ring three times before the person picks up, but the ringback tone you hear is independently generated on your side. This is why you sometimes hear ringing even when the call has failed to connect at all.

Step 3: They answer, and a direct path opens

When the other person picks up, the signaling conversation completes. Both sides now have the information they need to start exchanging actual audio.

Here is the important distinction: the signaling (the "I want to call this number, okay it is ringing, okay they answered" part) often goes through your VoIP provider's servers. But the actual voice audio typically flows on a more direct path between the two endpoints. In many cases, once the call is established, your voice data does not even pass through the VoIP provider's servers. It flows from your device through the internet to their device as directly as the network allows.

This is deliberate. Voice is time-sensitive. Every extra stop the audio makes adds delay. The fewer hops between your mouth and their ear, the more natural the conversation feels.

Step 4: Your microphone captures sound

Now you speak. The sound waves from your voice hit the microphone in your phone or headset. The microphone is a transducer: it converts the physical pressure waves of sound into electrical signals.

These electrical signals are analog. They are continuous, smooth waves that mirror the shape of the sound waves your voice produced. Your phone's hardware converts this analog signal into a digital one using an analog-to-digital converter (ADC). This process samples the sound wave thousands of times per second, typically 8,000 or 16,000 times, and records the amplitude at each sample as a number.

What you now have is a stream of numbers representing your voice. Thousands of numbers per second, each one a snapshot of what your voice sounded like at that instant.

Step 5: The codec compresses your voice

Raw digital audio is large. Sending it uncompressed would consume too much bandwidth, and bandwidth on the internet path between you and the other person is shared with everything else: their Netflix stream, your coworker's Zoom call, the backup job running in the server room.

So your phone compresses the audio using a codec (coder-decoder). The codec analyzes the stream of numbers and finds clever ways to represent the same sound with far fewer bits. Some codecs are simple and efficient, like G.711, which has been around since the 1970s and cuts the data roughly in half. Others are sophisticated, like Opus, which can compress voice down to a fraction of its original size while sounding nearly identical to the original.

The codec makes trade-offs. More compression means less bandwidth, but it also means the codec has to throw away more information. The art of codec design is figuring out which information the human ear will not miss. High frequencies above the range of normal speech. Subtle tonal variations below the threshold of perception. The codec strips these out and keeps what matters.

This compression happens in real time, continuously, as you speak. Your phone is encoding 20 to 60 milliseconds of audio at a time into tiny compressed chunks. Each chunk is about 10 to 150 bytes of data, depending on the codec. Not kilobytes. Bytes.

Step 6: Packets are built

Each compressed audio chunk gets wrapped in a packet. Think of a packet as an envelope. The audio data is the letter inside. The envelope has addressing information on the outside: where it came from, where it is going, a sequence number so the other side can put the chunks back in order, and a timestamp so the other side knows exactly when this chunk was recorded.

VoIP packets use a protocol called RTP (Real-time Transport Protocol) for the audio payload, which rides inside UDP (User Datagram Protocol) for transport, which rides inside IP (Internet Protocol) for addressing. Each layer adds its own envelope around the data.

The total packet, envelope and all, is usually between 60 and 200 bytes. Your phone produces roughly 50 of these packets every second during a call. That is one packet every 20 milliseconds.

Here is a critical design choice: VoIP uses UDP instead of TCP. When you load a web page, your browser uses TCP, which guarantees every packet arrives and retransmits any that get lost. UDP makes no such guarantee. If a packet is lost, it is gone forever.

This seems like a terrible idea until you think about it. If a voice packet arrives late because it was retransmitted, it is useless. The conversation has already moved on. Hearing a word 500 milliseconds after it was spoken would be more confusing than not hearing it at all. So VoIP deliberately chooses speed over reliability. Get the packet there fast, and if it does not make it, move on.

Step 7: Packets cross your local network

The first hop is the most overlooked and often the most problematic. Your voice packet has to get from your device to your router and out to the internet.

If you are on a wired Ethernet connection, this is fast and predictable. The packet goes down the cable to the switch, to the router, done. Milliseconds.

If you are on Wi-Fi, things get more interesting. Your device has to wait for a clear moment to transmit (Wi-Fi is a shared medium where devices take turns). It broadcasts the packet over radio waves to the access point. If there is interference from other Wi-Fi networks, Bluetooth devices, or that microwave oven in the break room, the packet might get corrupted and need to be retransmitted at the wireless level.

Your router may also be juggling dozens of other things: someone streaming video, a cloud backup uploading, a software update downloading. If the router is congested, your tiny voice packet sits in a queue behind larger data packets, waiting its turn. This is where Quality of Service (QoS) settings matter. A well-configured router recognizes voice packets and moves them to the front of the line.

The local network is where most VoIP quality problems originate. Not on the internet. Not at the VoIP provider. Right here, on the 30 feet of network between your phone and your router.

Step 8: Packets cross the internet

Now your packet leaves your network and enters the wider internet. This is where things get both remarkable and unpredictable.

Your ISP receives the packet and forwards it toward the destination. But "the internet" is not a single network. It is thousands of independent networks operated by different companies, all interconnected. Your packet might cross three, five, or fifteen different networks to reach the other person.

At each network boundary, routers make forwarding decisions. They look at the destination address and consult their routing tables to determine the best next hop. "Best" is a complex calculation involving available capacity, business relationships between networks, geographic proximity, and current congestion levels.

Your packet does not follow a predetermined path. Each packet is independently routed and might take a slightly different path than the packet before it. In practice, packets from the same call usually follow the same route because routing tables do not change that frequently, but there is no guarantee.

The physical journey is remarkable. If you are calling someone across the country, your voice packet might travel through fiber optic cables at the speed of light, covering thousands of miles in 20 to 40 milliseconds. Undersea cables, terrestrial fiber routes, peering points in major cities. All of this infrastructure exists, always running, carrying trillions of packets per second.

Each router the packet passes through adds a small amount of delay: the time to receive the packet, look up the destination, and forward it. Typically one to three milliseconds per hop. Over ten hops, that is 10 to 30 milliseconds of accumulated routing delay, plus the speed-of-light propagation time.

Step 9: Some packets do not make it

Here is the reality of the internet: not every packet arrives. Routers get congested and drop packets. Links develop errors. Equipment fails. On a typical internet path, 0.1% to 1% of packets might be lost on any given day.

For web browsing or email, this is invisible because TCP retransmits lost data. For VoIP, every lost packet is a tiny gap in the audio. A fraction of a second of silence or a brief glitch. At low loss rates, your ear and brain fill in the gaps and you barely notice. At higher loss rates, speech becomes choppy and robotic.

Packets also arrive with variable timing. They were sent every 20 milliseconds like clockwork, but the internet path introduces variable delays. One packet might arrive 22 milliseconds after the previous one. The next might arrive 17 milliseconds later. This variation is called jitter, and it is one of the main reasons VoIP quality degrades.

Step 10: The other side collects packets in a buffer

When packets start arriving at the other person's device, they do not get played immediately. Instead, they go into a jitter buffer.

The jitter buffer is a small waiting room. Packets check in and wait until it is their turn to be played. The buffer's job is to smooth out the timing variations introduced by the internet. Even though packets arrived at irregular intervals, the buffer releases them at perfectly regular intervals for playback.

This is a trade-off. The buffer adds delay, typically 20 to 60 milliseconds. But without it, the irregular packet arrival would produce constant clicking, gaps, and distortion in the audio. A little bit of added delay is a small price for smooth sound.

The buffer is adaptive. When jitter is low, the buffer shrinks to minimize delay. When jitter increases, the buffer grows to absorb the variation. If a packet arrives too late, after its playback time has already passed, the buffer discards it. From the listener's perspective, that late packet is indistinguishable from a lost packet.

Step 11: The codec decodes the audio

Each packet emerges from the jitter buffer in the correct order and at the correct time. The codec now reverses the compression from step 5.

It takes the compressed bytes and reconstructs the stream of audio samples. The reconstruction is not perfect. Compression is lossy; some information was discarded during encoding. But a good codec at a reasonable bitrate produces audio that is perceptually indistinguishable from the original for speech.

If a packet was lost and the buffer has a gap, modern codecs use a technique called packet loss concealment (PLC). The codec looks at the audio before and after the gap and interpolates, generating a best guess of what the missing audio sounded like. For short gaps, one or two packets, PLC is surprisingly effective. For longer gaps, there is only so much guessing can do.

Step 12: Digital becomes sound again

The decoded audio is now a stream of digital samples, just like what was captured by the microphone on the other end, minus whatever was lost to compression and network impairment.

Your phone's digital-to-analog converter (DAC) turns these numbers back into an electrical signal. That signal drives the speaker or earpiece, which vibrates a tiny membrane. Those vibrations create pressure waves in the air. Sound waves. Your voice, reconstructed from numbers, traveling the last inch from speaker to eardrum.

The entire process, from your voice hitting the microphone to sound coming out of the speaker on the other end, takes between 50 and 300 milliseconds. Under 150 milliseconds, conversation feels natural and real-time. Between 150 and 300 milliseconds, you start noticing delay and people begin talking over each other. Above 300 milliseconds, normal conversation becomes difficult.

All of this, fifty times a second

Everything described above happens for every 20-millisecond chunk of audio, continuously, for the entire duration of the call. Fifty times a second, your voice is captured, digitized, compressed, packetized, routed across the internet, buffered, decompressed, and played back. In both directions simultaneously.

A ten-minute phone call involves roughly 30,000 packets in each direction. 60,000 packets total, each one making its own journey across the network. If 59,700 of them arrive perfectly but 300 are lost or late, that is only 0.5% loss, and you will probably notice it.

This is what makes VoIP quality both impressive and fragile. The system works remarkably well almost all of the time. But the margin between "sounds perfect" and "sounds terrible" is thin. Small changes in network conditions, a congested router, a Wi-Fi interference spike, an ISP routing change, can shift the experience from seamless to frustrating.

Why this matters

Understanding this chain gives you power. When a call sounds bad, you are no longer guessing. You can reason about where in the chain the problem might be:

Choppy audio on your end only? Likely your local network or device. Steps 4 through 7.

Both sides sound bad? Could be the internet path between you. Steps 8 and 9.

Delay but otherwise clear? The audio is getting through but taking too long. Look at your internet connection type, geographic distance, or an overloaded jitter buffer. Steps 8 and 10.

Fine in the morning, bad in the afternoon? Network congestion that builds during business hours. Steps 7 and 8.

Bad on Wi-Fi, fine on Ethernet? Your wireless network is the bottleneck. Step 7.

Every VoIP problem maps to a step in this chain. Once you know the chain, troubleshooting becomes logical instead of random.

The testing gap

Here is the challenge: most of this chain is invisible to you. You cannot see packets traversing the internet. You cannot watch the jitter buffer making decisions. You cannot measure codec performance with a stopwatch.

Standard speed tests measure bandwidth, which tells you almost nothing about VoIP quality. You could have a 500 Mbps connection that is terrible for voice because of jitter and loss, or a 10 Mbps connection that is flawless because it is stable and consistent.

What you need is a test that simulates this entire chain: generates audio, encodes it, sends it as real packets across the network, and measures what happens at each step. Latency, jitter, packet loss, codec performance, all measured under conditions that mirror an actual phone call.

That is exactly what VoIP Test is building. Not a bandwidth test with a VoIP label on it. A real simulation of the audio path, from microphone to speaker, measuring quality where it actually matters.

Want to go deeper? Our VoIP From the Ground Up series covers each of these concepts in detail, from how traditional phone calls work to diagnosing specific quality problems. For the protocol-level details of call signaling, see our SIP Signaling series.