# VoIP Test – Full Content

> Browser-based VoIP quality testing platform. Test your network's ability to carry voice traffic and pinpoint where quality problems originate.

Website: https://voiptest.com

This document contains the complete text content of voiptest.com in one file: every tool description and every published blog post. If you only need part of the site, the navigable index at [/llms.txt](https://voiptest.com/llms.txt) is smaller and links to per-section files.

# Tools

## VoIP Quality Test

URL: https://voiptest.com/tools/voip-test
Status: Free and publicly available (no account required)

Real-time voice quality analysis using synthetic media streams. The browser generates reference audio via the Web Audio API and sends it as a real media track with proper voice codec encoding, real packet sizing, and DSCP marking. A supplementary data channel provides per-packet timing. No microphone permissions, no media server, no TURN infrastructure required.

Measures jitter, packet loss, latency, and MOS score using ITU-T G.107 scoring. Results show exactly where in the network path quality degrades.

## PCAP Analyzer

URL: https://voiptest.com/tools/pcap-analyzer
Status: Free with account (sign-in required)

Upload a pcap or pcapng packet capture for automated VoIP analysis. Extracts RTP streams, maps SIP dialogs, and calculates per-stream MOS, R-factor, burst/gap loss, and codec detection. Identifies common issues: one-way audio, codec mismatches, NAT traversal failures. Compatible with Wireshark, tcpdump, and tshark exports.

## SIP Call Stories

URL: https://voiptest.com/tools/sip-call-stories
Status: Free with account (sign-in required)

Upload a packet capture and get a plain-English story for every call in it. Lists all identified calls, then fully analyzes the selected call: outcome and timing, the decisive SIP response code explained with troubleshooting steps, codec negotiation findings, who ended the call, a full SIP ladder, and per-endpoint registration health. All analysis is deterministic, computed directly from the packets.

## Call Flow Designer

URL: https://voiptest.com/tools/ivr-planner
Status: Free with account (sign-in required)

Visual call flow designer for IVR trees. Design auto-attendants, queues, ring groups, time conditions, and extensions with a drag-and-drop graph builder. Auto-allocate extension numbers from a configurable range (3-5 digits). Generate call path stories (plain-English narratives for every path through the IVR tree). Export as print-ready PDF, structured Markdown report, or JSON for reimport. Built for VoIP providers and MSPs to plan customer IVR configurations.

## Carrier Lookup

URL: https://voiptest.com/tools/carrier-lookup
Status: Free and publicly available

Look up any phone number to find the carrier, line type (VoIP, mobile, landline), porting status, and location. Rate limited.

## SIP Response Codes

URL: https://voiptest.com/tools/sip-codes
Status: Free and publicly available

Searchable reference for all SIP status codes. Each code includes a plain-English explanation, troubleshooting steps, and example SIP messages with annotated headers. Filter by category (1xx through 6xx) or search by code number or keyword.

## Bandwidth Calculator

URL: https://voiptest.com/tools/bandwidth-calculator
Status: Free and publicly available

Calculate required bandwidth for VoIP deployments. Select codec (G.711, G.729, Opus, etc.), number of concurrent calls, and overhead factors. Shows per-call and total bandwidth requirements with protocol overhead breakdown.

## MOS Score Explorer

URL: https://voiptest.com/tools/mos-explorer
Status: Free and publicly available

Interactive tool to understand how codec selection, packet loss, latency, and jitter combine to affect MOS (Mean Opinion Score). Adjust parameters with sliders and see the resulting quality score in real time using ITU-T G.107 E-model calculations.

# Blog Series (84 posts across 7 series)

## Series: VoIP From the Ground Up

A 10-part series covering everything from how traditional phone calls work to diagnosing VoIP quality problems. Start here if you want to understand voice quality from first principles.

### Part 1: How Does a Phone Call Actually Work?

URL: https://voiptest.com/blog/how-does-a-phone-call-actually-work
Published: 2026-03-17
Tags: voip-fundamentals, telephone-history, voip-basics

*VoIP From the Ground Up: Part 1 of 10*

Before you can understand why internet phone calls sometimes sound terrible, you need to understand how phone calls worked before the internet existed. The original system was elegant, simple, and incredibly reliable. It also explains why we eventually had to move past it.

## A wire between two people

At its most basic, a phone call is just two people connected by a wire.

When you speak into a telephone handset, the microphone inside converts the vibrations of your voice into an electrical signal. That signal travels along a copper wire to the other person's handset, where a small speaker converts it back into sound. The whole thing happens in real time. There is no recording, no file, no waiting. The electricity moves and the other person hears you.

This is exactly how Alexander Graham Bell's original telephone worked in 1876, and the core idea, real-time conversion between sound and signal at each end, stayed the same for over a hundred years, even as what happened between the two handsets changed completely. By the late twentieth century the network core had gone digital: your voice was sampled and carried as bits between exchanges, with only the local loop to your house still analog copper.

## The problem of scale

A single wire between two people works fine. But what happens when you want a thousand people in a city to be able to call each other?

You cannot run a dedicated wire from every phone to every other phone. For just 1,000 phones, that would require nearly 500,000 separate cables. So instead, the telephone industry built central offices. Every phone in a neighborhood connected to a local central office with one pair of copper wires. When you picked up the phone and dialed, the equipment at the central office created a temporary connection between your wire and the other person's wire.

In the early days, human operators physically plugged cables together on a switchboard to make this happen. Later, mechanical switches automated the process. Eventually, electronic switches took over. But the concept never changed: pick up the phone, the network builds a dedicated path to the other phone, and that path stays open until you hang up.

## Circuit switching

This approach has a name: circuit switching. When you make a call, the network creates a circuit, a dedicated path from your phone through one or more switches to the other phone. In the early analog network, that was literally a continuous electrical path end to end. In the digital network that replaced it, the "circuit" became a logical resource: your voice is sampled and digitized at the edge, and the switches reserve a fixed time slot for your call in a time-division multiplexed (TDM) stream on each trunk along the way. Either way, the defining property is the same: that circuit is reserved exclusively for your conversation for the entire duration of the call. Nobody else can use it. It does not matter if you are talking, listening, or sitting in silence. The circuit stays open and dedicated to you.

This has some real advantages. The connection is consistent. There is no competition with other traffic. The audio quality depends almost entirely on the physical condition of the wire and equipment. If the call sounds good when it starts, it will sound good the whole way through.

But it also has a major drawback: waste. Studies have shown that during a typical phone conversation, actual speech is happening less than half the time. The rest is silence, pauses, listening. With circuit switching, all of that silence is consuming the same resources as active speech. The circuit does not care whether anyone is talking. It is locked in place either way.

## The network that held it all together

The traditional telephone network, known formally as the Public Switched Telephone Network, grew into one of the most reliable systems ever built. At its peak it connected billions of devices across the planet with an expected uptime that most modern technology still cannot match. When you picked up a landline phone, you got a dial tone. Period. Power outages did not matter because the phone line carried its own power. Internet problems did not matter because the internet was not involved.

This reliability was not an accident. It was the result of a century of engineering focused on one thing: making sure voice calls just worked. The network was purpose-built for voice. Every piece of equipment, every protocol, every design decision was optimized for carrying a live human conversation from one point to another.

## So why change?

If the traditional phone network was so reliable, why did we move to something else?

Cost and flexibility.

Circuit switching is expensive. Maintaining a global network of copper wires, central offices, and switching equipment requires enormous ongoing investment. Long distance calls were historically expensive precisely because they required dedicated circuits across long physical distances.

Meanwhile, by the 1990s, another type of network was growing fast: the internet. And the internet used a fundamentally different approach to moving information. Instead of dedicating a circuit to each conversation, it broke data into small pieces and sent those pieces independently across whatever path happened to be available. This was vastly more efficient. The same infrastructure that carried a web page could also carry an email, a file transfer, and, eventually, a voice call, carried as media packets (RTP, RFC 3550) set up by signaling protocols like SIP (RFC 3261).

The promise was compelling. If voice could ride on the same network as everything else, companies could stop paying for two separate systems. One network for data, one for voice. Why not just use one?

That question launched an entire industry. It also introduced a set of problems that the traditional phone network had already solved, problems that [VoIP](/blog/what-is-voip) users are still dealing with today.

## What comes next

In the next post, we will talk about what a network actually is and how data moves across one. Understanding this is the foundation for understanding why voice on the internet behaves differently than voice on a dedicated phone line.

---

*This is Part 1 of the [VoIP From the Ground Up](/blog?category=fundamentals) series. [Part 2: What Is a Network, and Why Should You Care?](/blog/what-is-a-network) covers how modern networks work and why they handle data differently than the old telephone system.*

---

### Part 2: What Is a Network, and Why Should You Care?

URL: https://voiptest.com/blog/what-is-a-network
Published: 2026-03-17
Tags: voip-fundamentals, networking-basics, voip-basics

*VoIP From the Ground Up: Part 2 of 10*

In the [last post](/blog/how-does-a-phone-call-actually-work), we talked about how the traditional phone system works: dedicated copper wires, circuit switching, and a network built from the ground up for voice. That system was reliable but expensive. The internet offered a cheaper alternative, but it works in a fundamentally different way.

Before we can talk about what makes internet phone calls different, we need to understand what a network actually is.

## The simplest possible network

A network is two or more devices connected so they can exchange information. That is it.

Two computers connected by a cable is a network. Your phone talking to your wireless router is a network. A thousand machines in a corporate office all wired into switches and routers is a network. The scale changes, the principles do not.

Every network, no matter how large, is really just a collection of devices that have agreed on a set of rules for how to talk to each other.

## Your local network

The network inside your home or office is called a local area network. This is the part you own and control.

In a typical setup, your [internet service provider](/blog/isp-foundation) gives you a modem that connects to the outside world. That modem connects to a router, which is the traffic cop for everything inside your building. The router connects to one or more switches, and those switches provide ports where you plug in computers, phones, printers, and anything else that needs network access. [Wireless access points](/blog/wired-vs-wifi-for-voip) extend the network to devices that do not have a cable.

All of these devices communicate with each other through the router and switches. When your laptop talks to your printer, that traffic stays entirely within your local network. It never touches the internet. Your router keeps track of who is who, and the switches handle getting data from one port to another.

The important thing to understand is that this piece of the path is yours. You bought the equipment, you plugged in the cables, and you are responsible for how well it works. If a switch is old and dropping traffic, that is your problem to solve. If your wireless access point is overloaded, that is on you. This will matter a lot when we get to [diagnosing voice quality issues](/blog/diagnosing-voip-problems) later in the series.

## The internet

The internet is not a single thing. It is a massive collection of networks owned by different companies and organizations, all connected to each other.

When your data leaves your building, it enters your internet service provider's network. From there, it may pass through several other networks before reaching its destination. Each of these networks is owned and operated independently. They connect to each other at exchange points, and they make agreements about how to pass traffic back and forth.

Think of it like a road system. Your local network is your driveway and private roads. Your internet service provider is the local highway system. The broader internet is the interstate system, maintained by dozens of different agencies, each responsible for their own stretch.

When you load a website, your request might pass through five or six different networks before reaching the server that hosts the page. The response takes a similar journey back. Each of these hops is a potential point where something can go wrong: congestion, equipment failure, misconfiguration, or just plain slow hardware.

This is the part of the path you do not control. And for voice calls, that matters enormously.

## The key difference from the phone network

Here is where networks diverge from the old telephone system.

The traditional phone network gave you a dedicated path. Once your call was connected, that path was yours alone. Nothing else shared it. Nothing interfered with it. The quality was consistent from start to finish because nothing was competing for the same resources.

A modern data network does not work this way. Nothing is reserved for your call. Your voice traffic converges onto the same switches, routers, and internet links as someone else's file download, someone's video stream, and a hundred background updates happening on devices you do not even know about.

This statistical sharing is dramatically more efficient than circuit switching because no resources sit idle. But it is worth being precise about *where* the sharing happens. A modern switched Ethernet LAN is not one shared medium: each wired device gets its own full-duplex link to its switch port, so your desk's cable is not competing with your neighbor's. The competition happens where traffic converges: on Wi-Fi, where every device on a channel takes turns using the same airtime; on switch uplinks, where many access ports funnel into one; and above all at the router's queue onto the internet link, which is almost always the narrowest point. When those convergence points are quiet, everything flows smoothly. When they get busy, something has to give.

The rules that govern how this competition plays out, how data gets prioritized (DiffServ service classes under RFC 4594 and Wi-Fi's WMM access categories are two examples), how conflicts get resolved, and how information actually moves from one device to another, are what make or break voice quality on a modern network. A [VoIP quality test](/tools/voip-test) measures exactly how well your network handles this competition when voice is in the mix.

## What comes next

In the next post, we will look at exactly how data moves across these networks. The answer involves breaking information into small independent pieces, and it explains both the genius and the headache of running voice calls over the internet.

---

*This is Part 2 of the [VoIP From the Ground Up](/blog?category=fundamentals) series. [Part 3: Packets, How Data Actually Moves](/blog/how-data-moves-in-packets) explains the mechanism networks use to send information.*

---

### Part 3: Packets: How Data Actually Moves

URL: https://voiptest.com/blog/how-data-moves-in-packets
Published: 2026-03-18
Tags: voip-fundamentals, packets-explained, networking-basics

*VoIP From the Ground Up: Part 3 of 10*

We have established that the internet is a shared network where all traffic competes for the same resources. But we have not explained *how* data actually gets from one place to another. The answer is the single most important concept in modern networking, and it is the reason VoIP works the way it does.

## The mailing analogy

Imagine you need to send a 300-page book to someone across the country. You have two options.

Option one: put the entire book in a box and ship it. Simple. But if the box gets lost, you lose everything. If the delivery route is congested, your entire book is stuck waiting. And nobody else can use that delivery truck while your box is on it.

Option two: tear out each page, put it in its own envelope, number the envelopes, and mail them individually. Each envelope can take a different route. If one gets lost, you only resend that single page. The postal system can handle your envelopes alongside everyone else's mail without dedicating any vehicle exclusively to you. The recipient collects all the envelopes and puts the pages back in order.

The internet chose option two.

## What is a packet?

Every piece of data sent across a network gets broken into small chunks called packets. An email, a webpage, a video stream, a voice call. All of it is split into packets before it leaves your device.

Each packet contains two things: a header and a payload. The header is the addressing information. It says where the packet came from, where it is going, and other bookkeeping details the network needs to route it correctly. One thing the IP header does *not* carry is a general "what order it belongs in" number: the IPv4 and IPv6 headers (RFC 8200) have no end-to-end sequence field. Ordering is the job of whatever protocol rides inside the packet: TCP numbers the bytes of its stream, and voice packets carry their own sequence numbers in RTP. The payload is the actual data, the chunk of the email or webpage or audio that this particular packet is carrying.

A single packet is small, typically somewhere between a few hundred and about 1,500 bytes. To put that in perspective, a single photo from your phone might require hundreds or thousands of packets to transmit.

## How packets travel

When your device sends a packet, it does not know or care about the full path to the destination. It only knows the next step: the router. Your device hands the packet to your router, and the router looks at the destination address in the header and decides where to send it next.

That next device does the same thing. It reads the header, looks up the best route it knows about, and forwards the packet to the next hop. This continues, device by device, until the packet reaches its destination. Each device along the way makes its own independent routing decision.

In principle, two packets going to the exact same destination could take different paths: one through Chicago, one through Dallas. In practice, networks work hard to avoid that. Where multiple equal-cost routes exist, routers and load balancers hash each *flow* (the addresses and ports of a connection) onto a single path, so all the packets of one conversation follow the same route. Packets do not roll the dice at every hop; paths shift when routing changes, not packet by packet, precisely because reordering a live stream causes trouble.

This is still fundamentally different from the old phone system. There is no dedicated circuit. There is no guaranteed or reserved path. Each packet is delivered on a best-effort basis.

## Reassembly

When packets arrive at the destination, they may occasionally be out of order: a route change mid-transfer, or parallel links inside one hop, can let a later packet slip ahead. The receiving device uses the sequence numbers that the transport or application protocol put in each packet (TCP's byte numbering, or RTP's sequence numbers for voice) to put everything back in the correct order.

For most types of data, this works beautifully. If you are downloading a file, it does not matter if the packets arrive out of order or if some take longer than others. Your device just waits until it has all of them, assembles them in the right sequence, and hands you the completed file. A few milliseconds of reordering is invisible because you were not expecting the result in real time.

This is why web browsing, email, and file transfers work so well on the internet. The slight disorder of packet-based delivery is completely hidden from you.

## The two transport methods

Networks use two main approaches for delivering packets, and the difference between them is critical for understanding VoIP.

The first approach is reliable delivery. Before sending data, your device establishes a connection with the destination. The data is tracked as a numbered stream of bytes, and the receiver sends back acknowledgments: cumulative ones that say "I have everything up to here," often deliberately delayed to cover several packets at once rather than one acknowledgment per packet (RFC 9293). If data goes missing, the sender automatically resends it. This guarantees that every piece of data arrives, in order, with nothing lost. Email, file downloads, and much of web browsing use this method. It is called Transmission Control Protocol. (Web traffic is no longer synonymous with TCP, though: HTTP/3 (RFC 9114) runs over QUIC, which builds its own reliability on top of UDP.)

The second approach is fast delivery. Your device just sends packets without establishing a connection first and without waiting for acknowledgments. If a packet gets lost, nobody resends it. It is simply gone. This sounds reckless, but it is faster because there is no overhead of tracking, acknowledging, and resending. This method is called User Datagram Protocol.

VoIP uses the fast delivery method: voice rides in RTP packets over UDP, and RTP adds sequence numbers and timestamps so the receiver can spot gaps and reorder, but RTP itself never retransmits. And the reason is time.

If a packet carrying a piece of your voice gets lost, by the time the network detected the loss, requested a resend, and delivered the replacement packet, the conversation would have moved on. That packet is no longer relevant. Resending a word you said 500 milliseconds ago would be worse than just skipping it. So VoIP accepts the loss and moves on.

This trade-off, speed over reliability, is what makes internet voice calls possible. It is also what makes them vulnerable. You can measure how well your connection handles this trade-off with a [VoIP quality test](/tools/voip-test). For more on how [packet loss](/blog/understanding-voip-packet-loss) specifically affects call quality, see our dedicated guide.

## Why this matters for voice

Everything we have covered in this post creates a specific set of challenges for voice traffic.

Packets can arrive out of order. Packets can be delayed by congestion. Packets can be lost entirely with no resend. And all of this is happening to your live conversation, where gaps, [stutters, and delays](/blog/choppy-robotic-audio) are immediately noticeable to the human ear.

For a web page, none of this matters. For a file download, none of this matters. But for a real-time voice conversation, every one of these behaviors is a potential quality problem.

The next post digs into exactly why voice is uniquely difficult on a packet-based network and what the specific failure modes sound like on a real call.

---

*This is Part 3 of the [VoIP From the Ground Up](/blog?category=fundamentals) series. [Part 4: Why Voice Is the Hardest Thing to Send Over a Network](/blog/why-voice-is-hard) explains what makes real-time audio so demanding compared to every other type of internet traffic.*

---

### Part 4: Why Your Network Is Good Enough for Everything Except Phone Calls

URL: https://voiptest.com/blog/why-voice-is-hard
Published: 2026-03-19
Tags: voip-fundamentals, voip-basics, latency

*VoIP From the Ground Up: Part 4 of 10*

Not all data is created equal. A network can drop, delay, or reorder packets carrying a webpage and you will never notice. Do the same thing to a voice call and the conversation falls apart. This post explains why.

## The real-time problem

Most internet traffic is not time-sensitive. When you click a link, your browser sends a request. The server responds. If the response takes 200 milliseconds or 400 milliseconds, you probably cannot tell the difference. If a few packets need to be resent because they were lost along the way, the total delay might increase slightly, but the page still loads correctly.

Voice does not work this way.

A phone conversation is a continuous, real-time, two-way exchange. When you say a word, the other person expects to hear it almost immediately. Not in one second. Not in half a second. The human brain is remarkably sensitive to conversational timing. One-way delays beyond about 150 milliseconds (the transmission-planning boundary cited in ITU-T G.114, not a point where audio suddenly fails) start to feel unnatural, and one-way delays beyond 300 milliseconds make normal conversation very difficult because both speakers start [talking over each other](/blog/audio-delay-talking-over).

This means voice traffic has a deadline. Every piece of audio has to arrive within a narrow time window or it is worthless. There is no "try again later." The moment has passed.

## The three enemies of voice quality

Packet-based networks introduce three specific problems for real-time audio. We touched on these briefly in earlier posts, but now it is time to name them clearly.

### Latency

Latency is the time it takes for a packet to travel from your device to the other person's device. It is usually measured in milliseconds.

Some amount of latency is unavoidable. The data has to physically travel through cables, get processed by routers, and cross potentially thousands of miles of infrastructure. Light in a fiber optic cable crosses the continental United States in roughly 21 milliseconds. Add in the processing time at each hop and the encoding and decoding of audio at each end, and you are already at 50 to 80 milliseconds even under ideal conditions.

The problem comes when latency gets high enough to disrupt the natural back-and-forth of conversation. At 150 milliseconds one way, you start noticing a slight delay. At 250 milliseconds, you are stepping on each other's words. At 400 milliseconds, it feels like talking on a satellite phone from the 1990s.

Latency itself does not make audio sound bad. It makes the *conversation* feel bad. The audio might be crystal clear, but the timing is wrong, and that breaks communication just as effectively as static or distortion.

### Jitter

Jitter is the variation in latency from one packet to the next. For a deeper look at jitter and its practical impact, see our guide on [what jitter is and why it matters](/blog/what-is-jitter-and-why-it-matters).

Imagine packets arriving at the destination. In a perfect world, they show up at perfectly regular intervals: one every 20 milliseconds, like clockwork. In reality, some arrive after 15 milliseconds, some after 25, some after 40. Network congestion, routing changes, and competition with other traffic all cause this variation.

The receiving device uses something called a jitter buffer to smooth this out. It collects incoming packets and holds them briefly to put them back in proper order and spacing before playing the audio. A larger buffer can absorb more variation, but it adds latency (because packets are sitting in the buffer waiting). A smaller buffer reduces delay but cannot handle as much variation, leading to gaps in the audio when packets arrive too late.

Jitter is what makes voices sound [choppy or robotic](/blog/choppy-robotic-audio). The audio is arriving, but it is arriving in an uneven rhythm that the receiving device cannot fully smooth out.

### Packet loss

[Packet loss](/blog/understanding-voip-packet-loss) is exactly what it sounds like: packets that never arrive at all.

As we discussed in the [previous post](/blog/how-data-moves-in-packets), VoIP uses a delivery method that does not resend lost packets. If a packet carrying 20 milliseconds of your voice disappears somewhere in the network, that piece of audio is just gone. The receiving device has to either play silence in its place or try to guess what the missing audio sounded like based on the packets that did arrive.

Modern audio codecs are surprisingly good at concealing small amounts of loss through packet loss concealment, and some add forward error correction that reconstructs missing packets outright. That is why there is no universal percentage at which loss becomes audible: the same loss rate can be invisible or ruinous depending on the codec, the packetization interval, and above all whether the loss is scattered or bursty. A fraction of a percent of loss spread evenly is typically well concealed; the same fraction concentrated in bursts of consecutive packets defeats concealment and produces obvious gaps and words that cut in and out. This distinction matters enough that RTCP XR (RFC 3611) reports burst and gap loss as separate metrics, and quality models like the ITU-T G.107 E-model penalize bursty loss more heavily than random loss at the same rate.

## Why other traffic does not have these problems

Web traffic, email, and file transfers all use the reliable delivery method we discussed in the [previous post](/blog/how-data-moves-in-packets). Lost packets get resent. Out-of-order packets get sorted. The application only sees the complete, correct data, even if the underlying network had all kinds of problems delivering it.

This works because those applications are not time-sensitive. If it takes an extra 100 milliseconds to resend a lost packet and complete your file download, nobody cares. The file is still correct when it arrives.

Voice cannot use this approach because the resend would arrive too late to be useful. So voice traffic is exposed to every imperfection in the network in a way that other traffic simply is not. The network problems are still there for web browsing and email. They are just hidden by the resend mechanism.

## The human factor

There is one more element that makes voice uniquely demanding: the listener.

Humans are extraordinarily sensitive to audio anomalies in speech. We evolved to process spoken language with incredible precision. We can detect gaps of just a few milliseconds in conversational audio. We instinctively know when timing is off. We notice tonal shifts, brief silences, and unnatural rhythms that we would never detect in, say, a music stream.

This means that voice quality issues that would be completely invisible in other applications become immediately obvious and irritating in a phone call. A 50 millisecond gap in a video stream is invisible. A 50 millisecond gap in a phone conversation is a speaker cutting out mid-word.

The bar for "good enough" is simply higher for voice than for almost anything else on the network. A [VoIP quality test](/tools/voip-test) measures the specific metrics that matter for this bar -- latency, jitter, and packet loss -- and the [MOS Explorer](/tools/mos-explorer) shows how those metrics translate into the perceived quality score that reflects what listeners actually hear.

## What comes next

Now that we understand why voice is so demanding, the next post puts it all together and explains what VoIP actually is, step by step, from the moment you speak into a microphone to the moment the other person hears your words.

---

*This is Part 4 of the [VoIP From the Ground Up](/blog?category=fundamentals) series. [Part 5: What Is VoIP, Really?](/blog/what-is-voip) walks through the full process of how a voice call works over the internet.*

---

### Part 5: What Is VoIP, Really?

URL: https://voiptest.com/blog/what-is-voip
Published: 2026-03-20
Tags: voip-fundamentals, voip-basics, codecs

*VoIP From the Ground Up: Part 5 of 10*

We have spent four posts building up to this. You understand how [phone calls used to work](/blog/how-does-a-phone-call-actually-work) over dedicated copper circuits. You know [what a network is](/blog/what-is-a-network) and how [data moves across it in packets](/blog/how-data-moves-in-packets). You understand [why voice is uniquely difficult](/blog/why-voice-is-hard) for a packet-based network.

Now we can talk about what Voice over Internet Protocol actually is, not as a marketing term, but as a mechanical process.

## The basic idea

VoIP is the process of taking a live human voice, converting it into digital data, splitting that data into packets, sending those packets over an internet protocol network, and converting them back into audible sound at the other end. All in real time.

That is the whole idea. The complexity is in the execution.

## Step by step

Here is what happens from the moment you speak into a VoIP phone to the moment the other person hears you.

### Step 1: Capture

Your phone's microphone picks up the sound waves from your voice and converts them into an analog electrical signal. This is identical to what happens on a traditional phone. The microphone does not know or care whether it is connected to a copper phone line or a digital network. It just turns sound into electricity.

### Step 2: Digitize

The analog signal from the microphone is converted into digital data. A component called an analog-to-digital converter samples the electrical signal thousands of times per second and records each sample as a number. The standard rate for voice is 8,000 samples per second, though some systems use higher rates for better quality.

This gives you a stream of numbers that represent the shape of your voice's sound wave at each instant. This is raw digital audio.

### Step 3: Encode

Raw digital audio uses a lot of bandwidth. Human speech has a lot of predictable patterns that can be represented more efficiently, so most VoIP systems encode the audio into a more compact form before sending it.

A codec (short for coder-decoder) takes the raw digital audio and encodes it into the format that will travel across the network. Many codecs compress heavily, but compression is not what defines a codec: G.711, for example, is little more than the PSTN's own companded PCM encoding at the full 64 kbps. Different codecs make different trade-offs between audio quality and bandwidth usage. Some prioritize crystal-clear audio at the cost of higher bandwidth. Others squeeze the audio down to a fraction of the size while still sounding acceptable.

Common VoIP codecs include G.711, which uses 64 kilobits per second and sounds very close to a traditional phone call, and G.729, which compresses down to about 8 kilobits per second at the cost of some audio fidelity. Newer codecs like Opus can [adapt dynamically](/blog/sdp-media-negotiation), adjusting compression on the fly based on network conditions. For more on how codecs affect quality scoring, see our post on [MOS scores](/blog/understanding-mos-scores).

### Step 4: Packetize

The compressed audio gets broken into small chunks, typically 10 to 30 milliseconds of audio per chunk. Each chunk is placed inside a packet along with header information that tells the network where it came from, where it is going, and what order it belongs in. An additional protocol layer called the Real-time Transport Protocol (RTP, RFC 3550) adds timing and sequencing information specifically designed for media streams.

At this point, your voice has been transformed from sound waves into numbered, addressed packets of data, ready to travel across a network alongside web traffic, email, and everything else.

### Step 5: Transmit

The packets leave your device, pass through your local network equipment (switches, router, firewall), cross your internet connection, enter your [internet service provider's](/blog/isp-foundation) network, traverse the broader internet through multiple hops, and eventually reach your VoIP provider's infrastructure. From there, the packets are routed to the other participant's connection and make the reverse journey into their local network and onto their phone.

Each packet travels independently. As we covered in [Part 3](/blog/how-data-moves-in-packets), they may take different routes. They may experience different amounts of delay. Some may not arrive at all.

### Step 6: Buffer

The receiving device collects the arriving packets and places them in a jitter buffer. This is a small holding area where packets wait briefly so the device can sort them into the correct order and smooth out variations in arrival timing. The buffer introduces a small amount of deliberate delay in exchange for more consistent audio playback.

### Step 7: Decode

The codec on the receiving end takes the encoded audio data from each packet and reverses the encoding, reconstructing the digital audio stream. If any packets were lost, the codec may attempt to fill in the gap by estimating what the missing audio sounded like based on the surrounding packets. This is called packet loss concealment.

### Step 8: Play

The digital audio is converted back to an analog electrical signal, which drives the speaker in the receiving phone's handset or headset. The listener hears your voice.

This entire sequence, all eight steps, is happening continuously in both directions for the entire duration of the call. And as a planning target, the total one-way time from your mouth to the other person's ear should stay below about 150 milliseconds (the transmission-planning boundary cited in ITU-T G.114) for the call to feel natural.

## What VoIP replaced

Looking at this process, you can see both the appeal and the risk of VoIP compared to the traditional phone system.

The traditional system had a dedicated circuit from end to end. The local loop between your phone and the central office was analog, but the trunk lines between central offices were digital, using PCM encoding since the 1960s, and the digital PSTN was never as untouched as nostalgia suggests. It sampled and multiplexed calls into TDM time slots, applied echo cancellation, and on expensive routes used compression (ADPCM and circuit multiplication equipment on international trunks) and even packetized segments; mobile networks compressed voice aggressively from the start. The real difference was the reservation: a dedicated circuit carried your call the whole way, with no competition from other types of traffic. Simple, reliable, and limited to one purpose.

VoIP replaced that with a complex chain of conversions, compressions, and routing decisions that all have to execute flawlessly in real time. The upside is that voice can now travel over the same infrastructure as everything else, saving enormous amounts of money and adding flexibility that was never possible with circuit switching. The downside is that every step in the chain is a potential failure point.

## The finger-pointing problem

Here is the practical reality that most VoIP users eventually face.

When a call sounds bad, the problem could be at any point in the chain. Your local network could be congested. Your internet connection could be dropping packets. Your internet service provider could have a routing issue. The path between your provider and your VoIP provider could be congested at a peering point. Your VoIP provider's infrastructure could be overloaded.

You will call your VoIP provider and they will tell you the problem is your internet connection. You will call your internet service provider and they will tell you the connection looks fine on their end. Neither one is necessarily lying. They just cannot see the full picture.

This is the core problem that VoIP Test was built to address: our free [VoIP quality test](/tools/voip-test) gives you independent data that shows exactly where in the chain the breakdown is happening.

## What comes next

The next two posts zoom in on the two halves of the path. First, we will look at [your local network](/blog/your-local-network), the part you own and control, and what you can do to optimize it for voice traffic. Then we will look at [the internet side](/blog/the-internet-path), the part you do not control, and what that means for diagnosing problems.

---

*This is Part 5 of the [VoIP From the Ground Up](/blog?category=fundamentals) series. [Part 6: Your Local Network, The Part You Control](/blog/your-local-network) covers the equipment and configuration that directly impacts call quality inside your building.*

---

### Part 6: Your Local Network: The Part You Control

URL: https://voiptest.com/blog/your-local-network
Published: 2026-03-21
Tags: voip-fundamentals, networking-basics, local-network

*VoIP From the Ground Up: Part 6 of 10*

When voice quality problems hit, there is a natural tendency to blame the VoIP provider or the internet connection. Sometimes that is the right call. But more often than people expect, the problem is inside their own building.

Your local network is the one piece of the entire voice path that you actually own and have the power to fix. Understanding what is in it and how it affects voice traffic is the most practical thing you can learn in this series.

## What is in your local network

A typical office or home network has a handful of key components. Each one plays a role in how voice traffic moves.

### The router

The router is the gateway between your local network and the [internet](/blog/how-internet-connections-work). All traffic entering or leaving your building passes through it. The router makes decisions about where to send packets, can prioritize certain types of traffic over others, and typically includes a firewall that filters out unwanted connections.

For VoIP, the router is critical. If it is underpowered and struggling to process traffic quickly, it adds latency to every packet. If its Quality of Service features are not configured, voice packets get treated the same as everything else and have to compete for bandwidth during busy periods.

### Switches

Switches are the connectors. They provide the physical ports where devices plug into the network with ethernet cables. When a device on one port needs to talk to a device on another port, the switch handles that connection.

In small environments, a single switch might handle everything. In larger offices, multiple switches are connected together, sometimes in a chain. Every switch a packet passes through adds a small amount of processing time. Older or lower-quality switches can also introduce errors or drop packets under heavy load.

Managed switches give you the ability to configure traffic prioritization at the port level. Unmanaged switches treat all traffic equally, which means voice packets get no special treatment.

### Wireless access points

Wireless access points let devices connect to the network without a cable. They are convenient, but they introduce a set of problems that wired connections do not have. For a detailed comparison, see our post on [wired vs. Wi-Fi for VoIP](/blog/wired-vs-wifi-for-voip).

Wireless is a shared medium in a very literal sense. Every device connected to the same access point is competing for airtime on the same radio frequency. The access point can only talk to one device at a time, so it rapidly switches between them. This adds latency and jitter that are inherent to the technology, not the result of a misconfiguration.

Wireless signals are also susceptible to interference from other devices operating on the same frequencies: neighboring wireless networks, Bluetooth devices, microwave ovens, cordless phones, and various other electronics. Physical obstacles like walls, glass, and metal further degrade the signal.

For VoIP, wireless is a significant risk factor. Not because it cannot work, but because it introduces variability that wired connections simply do not have. A wired connection to a switch delivers consistent, predictable performance. A wireless connection delivers variable performance that changes based on how many devices are active, what the radio environment looks like at that moment, and where the device is physically located.

### Cables

It sounds basic, but cabling matters. A damaged ethernet cable can cause intermittent packet loss that is maddening to diagnose because it comes and goes. Cables that are too long (beyond 100 meters for standard ethernet) degrade signal quality. Cables run alongside electrical wiring can pick up interference.

Old Category 5 [cabling](/blog/new-building-infrastructure) (not to be confused with Category 5e) in a building that has been upgraded to gigabit networking is a problem. The 1000BASE-T standard requires Category 5e as a minimum. Plain Category 5 cables will typically fail to negotiate a gigabit link at all, falling back to 100 megabits or refusing to connect reliably.

## The bandwidth question

People often assume that poor VoIP quality means they need a faster internet connection. This is sometimes true, but less often than you would think.

A single VoIP call using the common G.711 codec requires roughly 85 to 100 kilobits per second in each direction when you account for all the overhead. That is almost nothing by modern standards. A typical business internet connection measured in tens or hundreds of megabits per second can theoretically carry hundreds of simultaneous calls.

The issue is usually not total bandwidth. It is what happens to the bandwidth during the moments of peak usage.

When someone in the office starts a large file download, kicks off a cloud backup, or joins a video conference, that traffic can temporarily consume enough bandwidth to crowd out voice packets. The voice call only needs a tiny slice of the connection, but it needs that slice *consistently*. A file download that temporarily saturates the connection for two seconds causes a two-second disruption to every active call, even though total bandwidth was adequate 99% of the time.

This is why bandwidth alone is a misleading metric for VoIP readiness. What matters is whether the network can guarantee consistent, low-latency delivery for voice traffic even when other applications are competing for the same connection.

## Common local network problems

Based on real-world troubleshooting, these are the local network issues that most frequently degrade voice quality.

**No traffic prioritization.** Voice packets are treated identically to all other traffic. During congestion, they are delayed or dropped like everything else. Configuring Quality of Service on your router and switches to prioritize voice is the single highest-impact change most networks can make. We cover [Quality of Service in detail](/blog/quality-of-service-explained) later in the series.

**VoIP phones on wireless.** Desk phones, softphone applications, or headsets connected over wireless instead of ethernet. Every wireless connection adds [jitter](/blog/what-is-jitter-and-why-it-matters) and latency that a wired connection avoids entirely.

**Daisy-chained consumer switches.** Small unmanaged switches plugged into other small unmanaged switches to add more ports. Each hop adds latency and none of them offer traffic prioritization. A single managed switch with enough ports is almost always the better solution.

**Old or damaged cabling.** Intermittent physical layer problems that cause sporadic packet loss. These can be extremely difficult to pinpoint because the problem comes and goes, often correlating with temperature changes or physical movement near the cable.

**Overloaded router.** A consumer-grade router handling traffic for 20 or 30 devices in a small office. The router's processor cannot keep up, adding latency to all traffic and sometimes dropping packets entirely when its buffers fill up.

**No network segmentation.** Voice traffic and data traffic sharing the same flat network with no separation. A broadcast storm or misbehaving device can affect everything, including active calls.

## What you can actually do

The good news is that local network problems are the most fixable problems in the VoIP quality chain. You own the equipment. You control the configuration.

Start with the physical layer. Make sure VoIP endpoints are on wired connections wherever possible. Verify that cables are in good condition and rated for the speeds your network requires. Replace consumer-grade equipment with business-grade hardware in any environment where call quality matters.

Then move to configuration. Enable Quality of Service on your router and managed switches. If your network is large enough, put voice traffic on its own virtual local area network to isolate it from data traffic. Monitor your network during business hours to identify bandwidth hogs and usage spikes.

These steps will not solve every voice quality problem. Some problems originate beyond your network boundary, and those require a different approach. But fixing the local side first eliminates the most common causes and gives you a clean baseline for diagnosing anything that remains. Running a [VoIP quality test](/tools/voip-test) before and after making changes gives you concrete data on whether your local network improvements actually moved the needle.

## What comes next

The next post covers the other side of the equation: the internet, the long stretch of infrastructure between your building and your VoIP provider that you do not own and cannot directly fix. Understanding that part of the path is essential for knowing when the problem is not yours to solve and having the data to prove it.

---

*This is Part 6 of the [VoIP From the Ground Up](/blog?category=fundamentals) series. [Part 7: The Internet, The Part You Don't Control](/blog/the-internet-path) covers what happens to your voice traffic after it leaves your building.*

---

### Part 7: The Internet: The Part You Don't Control

URL: https://voiptest.com/blog/the-internet-path
Published: 2026-03-22
Tags: voip-fundamentals, internet-path, isp

*VoIP From the Ground Up: Part 7 of 10*

In the [last post](/blog/your-local-network) we covered the local network, the piece of the voice path you own and can fix. This post covers everything else: the long journey your voice packets take between your building and your VoIP provider's infrastructure.

This is the part that causes the most frustration for VoIP users, because when problems happen here, you cannot directly fix them. You can only identify them and put pressure on the right people.

## What the path looks like

When a voice packet leaves your router, it enters your internet service provider's network. From there, it may pass through several other networks before reaching your VoIP provider. A typical path might look like this:

Your phone sends a packet. It crosses your local network to your router. Your router forwards it to your internet service provider's equipment, usually at a local facility. Your provider's network routes it through one or more of their own facilities, possibly across the region. At some point, the packet leaves your provider's network and enters another network, either through a direct connection (called peering) or through a third-party transit provider. It may cross one or more additional networks before finally reaching the network where your VoIP provider's servers live.

Each of these transitions is called a hop. A voice packet might cross 10 to 20 hops between your phone and the VoIP provider. Every hop is a router making a forwarding decision, and every hop is a potential point of failure.

## Where problems happen

### Your internet service provider's last mile

The "last mile" is the connection between your internet service provider's local infrastructure and your building. It might be a fiber optic cable, a coaxial cable, a copper line, or even a fixed wireless link. This segment is often the most congested part of the path because it is shared with your neighbors.

[Cable internet](/blog/cable-internet), for example, uses a shared infrastructure at the neighborhood level. During peak evening hours when everyone is streaming video, available bandwidth can decrease significantly. Even a business-grade connection can be affected if it shares underlying infrastructure with residential customers.

[Fiber connections](/blog/fiber-internet) are generally more consistent, but they are not immune to problems. A misconfigured device at the provider's end, a congested aggregation point, or a physical cable issue can all introduce latency or loss.

### Peering points

Peering points are where different networks connect to each other and agree to exchange traffic. Major internet exchange facilities handle enormous volumes of data, and when traffic between two specific networks exceeds the capacity of their connection, packets get dropped.

Peering disputes are a known source of VoIP quality problems. If your internet service provider and your VoIP provider's network do not have a direct peering relationship, your voice traffic might take an indirect route through one or more intermediary networks. Each additional network adds hops, latency, and potential points of congestion.

These disputes and capacity limitations are completely invisible to you as an end user. Good VoIP providers actively monitor path quality and may detect peering congestion on their end, but your internet service provider may not even be aware of it. Neither side has full visibility into every network in between.

### Transit networks

Large backbone networks carry traffic across long distances. They are generally well-maintained and have significant capacity, but they are not immune to problems. Equipment failures, fiber cuts, and routing changes can all cause sudden increases in latency or [packet loss](/blog/understanding-voip-packet-loss) on specific paths.

Routing changes are particularly sneaky. The internet's routing system is dynamic. The path your voice packets take at 9:00 in the morning might be different from the path they take at 2:00 in the afternoon. To be clear, this is change over time, not packet-by-packet chaos: routers typically hash all the packets of a single flow -- one call's RTP stream (RFC 3550) -- onto the same path, so the packets within one call normally follow a consistent route. But when routes shift, the whole flow moves. A routing change might send your traffic through a more congested path, degrading quality, and then revert later in the day. Intermittent quality problems that seem to happen at random are sometimes caused by temporary routing shifts that are nearly impossible to predict.

### Geographic distance

Physics cannot be negotiated with. Light in a fiber optic cable travels at roughly two-thirds the speed of light in a vacuum. A round trip from New York to Los Angeles and back takes approximately 60 milliseconds just for the propagation component -- the speed-of-light travel time -- before adding the other kinds of delay a packet accumulates: serialization delay (pushing the bits onto each link), forwarding delay at each router, and queuing delay when a router is busy. Those components behave differently -- propagation is fixed by geography, queuing varies with congestion -- which is why it helps to keep them separate when diagnosing.

For domestic calls, this is manageable. For international calls, especially to distant regions, the one-way latency from distance alone can push close to 150 milliseconds -- the figure ITU-T G.114 uses as a one-way transmission-planning boundary. That is planning guidance, not a cliff where audio suddenly fails; the conversational effect depends on the total mouth-to-ear delay and how well echo is controlled. But add network congestion and processing overhead on top of that baseline, and you can end up with calls that sound fine but feel impossible to have a normal conversation on.

## Why you cannot see the problem

When you run a speed test, you are measuring the bandwidth and latency between your device and a speed test server, usually located at your internet service provider's facility or a nearby data center. This tells you almost nothing about the quality of the path to your VoIP provider.

Your internet connection might show 200 megabits per second download, 50 megabits per second upload, and 10 milliseconds latency to the speed test server. Great numbers. But your VoIP traffic is not going to the speed test server. It is going to your VoIP provider's infrastructure, which might be in a completely different location, crossing different networks, through different peering points.

The speed test tells you that your last mile is fine. It does not tell you anything about hops 5 through 15 on the path to your VoIP provider. A congested peering point at hop 8 will never show up in a speed test. A [VoIP quality test](/tools/voip-test) measures what actually matters for calls -- latency, jitter, and packet loss on a path that resembles real voice traffic -- rather than raw throughput to a nearby server.

This is exactly why the "have you run a speed test?" response from your VoIP provider is so unhelpful. It measures the wrong thing.

## The blame game, revisited

Here is the pattern that plays out thousands of times a day at businesses across the world.

The phones sound terrible. You call your VoIP provider. They check their systems and report no issues on their end. They suggest you call your internet service provider. You call your internet service provider. They run a line test, see no errors, and tell you the connection is fine. You are now stuck between two companies, each claiming the problem is not theirs, with no way to prove where the issue actually is.

Both companies are often telling the truth as far as they can see. Your internet service provider can see the health of the last mile connection. Your VoIP provider can see the health of their own infrastructure. But neither one has visibility into the networks between them. The problem could be at a peering point, at a transit provider, or at an aggregation point that neither company monitors.

Without independent measurement that covers the entire path, you have no leverage and no way to hold the right party accountable.

## What you can do

You cannot fix a congested peering point or reroute traffic through a backbone network. But you can take steps to improve your position.

**Get a [dedicated internet connection](/blog/dedicated-internet-access) for voice.** If your budget allows it, a separate internet connection used exclusively for VoIP traffic eliminates competition with data traffic on your local internet link. This does not solve problems in the middle of the path, but it removes your own connection as a variable.

**Choose a VoIP provider with good peering.** Providers who maintain direct peering relationships with major internet service providers deliver more consistent quality than those who rely entirely on transit networks. Ask your VoIP provider about their network architecture and peering relationships. If they cannot answer, that tells you something.

**Run path-specific tests.** Tools like traceroute can show you the individual hops between your network and your VoIP provider. While they do not perfectly simulate voice traffic, they can reveal where latency spikes or packet loss is occurring along the path. Running these tests during a quality problem gives you data you can bring to your provider with a specific hop identified.

**Document everything.** When quality problems occur, note the time, duration, and symptoms. Run diagnostic tests during the issue, not after. Intermittent problems are impossible to investigate after the fact. Having timestamped data that correlates with specific network path measurements gives your provider something concrete to investigate.

## What comes next

Now that we understand both halves of the path, the local network and the internet, the next post takes a deeper technical look at the three metrics that define voice quality: latency, jitter, and packet loss. We will cover how they are measured, what targets are reasonable to aim for, and how they interact with each other.

---

*This is Part 7 of the [VoIP From the Ground Up](/blog?category=fundamentals) series. [Part 8: Latency, Jitter, and Packet Loss in Detail](/blog/latency-jitter-packet-loss-details) provides the technical depth on the three metrics that define whether a call sounds good or terrible.*

---

### Part 8: Latency, Jitter, and Packet Loss: The Details

URL: https://voiptest.com/blog/latency-jitter-packet-loss-details
Published: 2026-03-23
Tags: voip-fundamentals, latency, jitter, call-quality

*VoIP From the Ground Up: Part 8 of 10*

We introduced the three enemies of voice quality in [Part 4](/blog/why-voice-is-hard). This post goes deeper. If you have been following the series, you now understand what a network is, how packets move, and why voice is uniquely sensitive to network conditions. This is where we get into the specific numbers and mechanics that separate a good call from a bad one.

## Latency in depth

Latency is the total time it takes for audio to travel from your mouth to the other person's ear. It is the sum of several components, and understanding what contributes to it helps explain why some latency is fixable and some is not.

### Where latency comes from

**Codec processing delay.** Encoding your voice into compressed digital data takes time. Most modern codecs introduce between 1 and 30 milliseconds of delay depending on the algorithm and the frame size used. The G.711 codec, which does minimal compression, has almost no codec delay. More aggressive codecs like G.729 require more processing time.

**Packetization delay.** The codec produces audio in chunks, typically 10 to 30 milliseconds per chunk. A 20 millisecond packetization interval means the codec has to wait 20 milliseconds to collect enough audio to fill one packet before it can send anything. You can reduce this by using smaller intervals, but smaller packets mean more packets per second, which increases overhead on the network.

**Queuing delay.** At every router and switch along the path, packets may have to wait in a queue before being forwarded. If the device is busy processing other traffic, your voice packet sits in a buffer until it is its turn. During periods of congestion, queuing delay can spike dramatically and unpredictably.

**Transmission delay.** The time it takes to physically push the packet onto the wire. On modern high-speed connections this is negligible, but on slower links (some older broadband connections, for example) it can add up, especially for larger packets.

**Propagation delay.** The speed-of-light limitation. Even on fiber, signals take roughly 5 milliseconds to travel 1,000 kilometers. This component is fixed by geography and cannot be reduced without physically moving the endpoints closer together.

**Jitter buffer delay.** The receiving device deliberately holds packets in a buffer to smooth out arrival time variations. This intentional delay typically adds between 20 and 60 milliseconds, depending on how the buffer is configured and how much [jitter](/blog/what-is-jitter-and-why-it-matters) it needs to absorb.

### Adding it all up

For a call between two locations in the same city, total one-way latency might be 30 to 60 milliseconds under good conditions. Between opposite coasts of the United States, 60 to 120 milliseconds is typical. International calls can easily exceed 150 to 200 milliseconds.

The International Telecommunication Union's transmission-planning recommendation, ITU-T G.114, cites 150 milliseconds one-way as the boundary below which most applications are essentially unaffected. Between roughly 150 and 300 milliseconds one-way, the delay becomes increasingly noticeable and starts disrupting natural conversation flow. Above 300 milliseconds, real-time conversation is seriously impaired.

It is worth being precise about what these numbers are. They are planning guidance grounded in decades of research into how humans perceive conversational timing, not a point at which audio suddenly fails. Quality degrades gradually as delay grows, and the conversational effect depends on the total mouth-to-ear delay and on how well echo is controlled -- a call with poor echo cancellation feels worse at a given delay than one without. The 150 millisecond figure is roughly where the gap between speaking and hearing a response becomes long enough that both speakers begin to misread conversational cues and talk over each other.

## Jitter in depth

Jitter is the variation in packet arrival times. If latency were perfectly consistent, every packet arriving exactly 20 milliseconds after the last, there would be no jitter. In reality, network conditions change from moment to moment, and each packet's journey is slightly different.

### Measuring jitter

In practice, VoIP endpoints report the interarrival jitter statistic defined in RFC 3550, the RTP specification: a running, exponentially smoothed estimate of how much packet spacing deviates from the expected interval. Intuitively, if packets are supposed to arrive every 20 milliseconds, and the actual gaps are 18, 22, 19, 25, 17, and 31 milliseconds, the jitter estimate tracks the typical amount by which those gaps differ from 20 milliseconds. Because it is a statistical estimate, a single reported number summarizes behavior over time rather than capturing every individual spike; extensions like RTCP XR (RFC 3611) add detail such as how many packets arrived too late to play.

A few milliseconds of jitter is normal and harmless. The jitter buffer at the receiving end absorbs it easily. Problems start when jitter exceeds the capacity of the buffer.

### The jitter buffer trade-off

The jitter buffer is one of the most important and least understood components in VoIP. It works by adding intentional delay to create a cushion for absorbing timing variations.

Imagine packets arriving at irregular intervals. Without a buffer, the receiving device would try to play each packet the instant it arrived. The result would be audio that speeds up and slows down as packet spacing varies. With a buffer, the device collects packets and plays them at a steady rate, smoothing out the irregularities.

The trade-off is direct. A larger buffer can absorb more jitter, but it adds more latency. A 60 millisecond buffer adds 60 milliseconds to the total delay. A smaller buffer reduces delay but cannot handle as much variation. When a packet arrives too late to make it into the buffer's playback window, it is discarded as if it were lost.

This means that high jitter effectively becomes [packet loss](/blog/understanding-voip-packet-loss). A packet that arrives 80 milliseconds late on a system with a 40 millisecond jitter buffer is thrown away. The audio it carried is gone. From the listener's perspective, there is no difference between a packet that was genuinely lost in the network and one that arrived too late to be useful.

Most VoIP systems use adaptive jitter buffers that automatically adjust their size based on observed network conditions. When the network is stable, the buffer shrinks to minimize delay. When jitter increases, the buffer grows to absorb it. This helps, but it is a reactive system. Sudden spikes in jitter can overwhelm the buffer before it has time to adapt.

### Target jitter values

There is no standards-mandated jitter threshold -- what a given level of jitter does to a call depends on the codec, the endpoint's buffer behavior, and how much delay budget is left after everything else. But as operating targets, the following bands are widely used: for consistently good voice quality, aim to keep average jitter below 20 milliseconds. Jitter between 20 and 50 milliseconds is usually manageable with a well-configured buffer, at the cost of noticeable added latency. Above 50 milliseconds, call quality tends to degrade even with aggressive buffering, because the buffer has to add so much delay that the conversation starts to feel laggy -- the damage arrives as buffer delay and late-packet discard rather than as "jitter" directly.

## Packet loss in depth

Packet loss is the percentage of packets that are sent but never arrive. For VoIP, which uses a delivery method that does not resend lost packets, any lost packet represents a permanent gap in the audio.

### What packet loss sounds like

The effect of packet loss on audio depends on how much is lost, how it is distributed, and what the codec can do about it -- the concealment and any forward error correction built into the codec, and the packetization interval, all shift where the pain starts. One thing that does not change with the codec: a lost 20 millisecond packet removes 20 milliseconds of audio whether its payload was G.711 or G.729. What differs is how convincingly the decoder can paper over the hole. The percentage bands below are rough guides, not fixed thresholds.

**Random, low-level loss (below 1%).** Individual packets go missing at irregular intervals. Modern codecs conceal this with packet loss concealment, which extrapolates the missing audio from what has already been received -- typically by extending the pitch and energy of the preceding packets. (A real-time decoder generally cannot borrow from *future* audio to fill a gap without deliberately adding delay, which is why concealment quality falls off quickly as gaps get longer.) Most listeners will not notice anything wrong at this level.

**Random, moderate loss (1 to 3%).** Concealment algorithms start to struggle. Listeners hear occasional brief dropouts, words that clip at the beginning or end, or subtle artifacts that sound slightly robotic. The call is usable but clearly impaired.

**Random, high loss (3 to 5%).** Frequent and obvious gaps. Words and sometimes entire phrases go missing. The listener has to ask the speaker to repeat themselves regularly. Business communication becomes frustrating and unreliable.

**Burst loss.** Instead of losing individual packets at random, you lose multiple consecutive packets at once. Even a short burst (50 to 100 milliseconds) creates a gap that concealment cannot fill. The listener hears a clear dropout, as if someone [briefly muted the microphone](/blog/choppy-robotic-audio). Burst loss is often caused by network equipment that drops its entire buffer when overwhelmed, rather than dropping packets randomly.

### The relationship between the three

Latency, jitter, and packet loss are not independent problems. They interact in ways that make quality worse than any single metric would suggest.

High jitter causes effective packet loss through the jitter buffer mechanism described above. High latency combined with even moderate jitter makes conversations significantly harder than either problem alone, because the increased delay amplifies the awkwardness of timing mismatches. Packet loss on top of already-high latency is particularly destructive because the codec's concealment algorithms have less margin to work with when the overall timing is already tight.

This is why evaluating VoIP quality requires looking at all three metrics together, not in isolation -- and why our [VoIP quality test](/tools/voip-test) measures all three simultaneously. A call path with 80 milliseconds latency, 10 milliseconds jitter, and 0.5% loss will sound fine. A path with 120 milliseconds latency, 35 milliseconds jitter, and 2% loss will be miserable, not because any single number is catastrophic, but because the combination exceeds what the system can compensate for.

## The MOS score

The industry's standard way of collapsing all of these metrics into a single quality rating is the Mean Opinion Score. We have a dedicated post on this topic, [MOS Scores Explained](/blog/understanding-mos-scores), if you want the full breakdown. The short version is that MOS rates call quality on a scale from 1 (unusable) to 5 (excellent), and computational models like the ITU-T G.107 E-model can estimate it from measured network conditions without needing a panel of human listeners. One mechanical detail worth knowing: the E-model's inputs are delay and loss, not jitter directly. Jitter enters the calculation only after being converted into its real-world consequences -- the extra delay the jitter buffer adds, and the packets discarded for arriving too late, which count as loss. That is exactly the buffer mechanism described above, formalized into a planning model.

## What comes next

Now that we understand the metrics, the next post covers the most powerful tool available for protecting voice quality on the network you control: Quality of Service. This is where we move from diagnosing problems to actively preventing them.

---

*This is Part 8 of the [VoIP From the Ground Up](/blog?category=fundamentals) series. [Part 9: Quality of Service, Telling Your Network What Matters](/blog/quality-of-service-explained) covers how to configure your network to prioritize voice traffic over everything else.*

---

### Part 9: Quality of Service: Telling Your Network What Matters

URL: https://voiptest.com/blog/quality-of-service-explained
Published: 2026-03-24
Tags: voip-fundamentals, quality-of-service, network-configuration

*VoIP From the Ground Up: Part 9 of 10*

Everything we have covered so far points to one central truth: [voice traffic needs consistent, low-latency delivery](/blog/why-voice-is-hard), and the default behavior of a network is to treat all traffic equally. Quality of Service is how you override that default and tell your network that voice packets matter more than file downloads.

This post explains what Quality of Service is, how it works at a conceptual level, and where its real boundaries are. QoS is a useful tool in specific situations, but the VoIP industry has a habit of presenting it as a universal fix. It is not. Understanding what it actually does -- and what it cannot do -- matters more than knowing how to configure it.

## The problem Quality of Service solves

By default, a router or switch handles packets on a best-effort basis. Modern switches, routers, and operating systems usually ship with several hardware and software queues even before you configure anything, but without a policy telling them which traffic belongs where, packets are not sorted by what they contain, and everything effectively waits its turn together. When the network is quiet, this is fine. Everything gets processed quickly and there is no meaningful delay.

When the network gets busy, the queue fills up. Packets start waiting longer. If the queue overflows, packets get dropped entirely. And the network has no way of knowing that the packet it just dropped was carrying someone's voice on an active phone call while the packet it kept was part of a software update downloading in the background.

Without Quality of Service, a single large file transfer or cloud backup can degrade every active voice call on the network. Not because there is not enough total bandwidth, but because the router treats a voice packet with a 20 millisecond deadline the same as a backup packet that nobody would notice if it arrived a full second later.

## How Quality of Service works

Quality of Service is not a single technology. It is a collection of mechanisms that work together to give certain types of traffic preferential treatment. The core concept has three parts: identification, marking, and queuing.

### Identification

First, the network has to recognize which packets contain voice traffic. This can be done several ways. Some systems look at the source or destination address to identify traffic coming from or going to known VoIP devices. Others examine the port numbers in the packet headers, since VoIP protocols tend to use specific port ranges. In more sophisticated setups, devices are placed on dedicated network segments so that any traffic on that segment is known to be voice.

### Marking

Once voice traffic is identified, it gets marked. Marking means writing a value into a field in the packet header that other network devices can read. The most common system uses a field called Differentiated Services Code Point, which is a 6-bit value in the header of every packet.

The conventional value for voice traffic is 46, which corresponds to Expedited Forwarding, RFC 4594's recommended marking for telephony media (its recommendation for telephony *signaling* is CS5). This is a recommendation, not a mandate; deployments can and do differ. (Higher values like CS6 and CS7 exist but are reserved for network control traffic such as routing protocols, not for application data.) When a VoIP phone sends a packet, it typically marks it with this value automatically. When a router or switch sees this marking, it knows to treat the packet as high-priority.

The marking system only works if every device along the path respects it. On your local network, you control this. On the internet, you do not.

A DSCP value is only a marking, and every administrative domain along the path decides for itself what to do with it: trust it, remark it, carry it inside a tunnel, or ignore it. Internet service providers vary: some remark customer traffic to a default class at their edge, some pass markings through without acting on them, some honor them within their own network. What they generally do not do is grant priority queuing to arbitrary customer markings; if they did, everyone would mark all their traffic as high priority and the system would be meaningless. End-to-end honored QoS is the domain of dedicated enterprise circuits with contractual SLA commitments, which cost significantly more than standard business internet.

This means that for the vast majority of VoIP deployments, DSCP markings reliably buy you priority only within your own network. Once a packet crosses into a domain you do not administer, the marking may survive or may not, but you cannot count on it doing anything, and the packet travels the same best-effort path as everything else on the internet.

### Queuing

Queuing is where the actual prioritization happens. Instead of a single first-come, first-served queue, the router or switch maintains multiple queues, each with a different priority level.

When a high-priority voice packet arrives, it goes into a dedicated queue that gets serviced first. When a low-priority file transfer packet arrives, it goes into a different queue that only gets serviced when the high-priority queue is empty or when its minimum guaranteed bandwidth allocation is met.

The result is that during periods of congestion, voice packets experience minimal delay while lower-priority traffic absorbs the wait. The voice call stays clear while the file download slows down slightly. This is almost always the right trade-off, since the file download does not care about an extra hundred milliseconds of delay, but the voice call absolutely does.

## Types of queuing

Different queuing strategies offer different trade-offs, and understanding the basics helps when evaluating equipment or reading configuration guides.

**Strict priority queuing** always processes the high-priority queue first. Voice packets get sent immediately, no matter what. The risk is that if something floods the high-priority queue (either by accident or misconfiguration), it can starve everything else on the network. This is usually mitigated by putting a bandwidth cap on the priority queue.

**Weighted fair queuing** gives each queue a proportional share of available bandwidth. The voice queue might get 30% of bandwidth guaranteed, with the ability to use more when available. This prevents starvation of other traffic but does not provide the absolute lowest latency for voice.

**Low-latency queuing** combines both approaches. Voice traffic gets a strict priority queue with a bandwidth cap, and all other traffic is handled by weighted fair queuing. This is the most common approach for networks that carry voice traffic because it gives voice the lowest possible latency while still preventing the priority queue from consuming all resources.

## Where to apply Quality of Service

Quality of Service needs to be configured at specific points in the network to be effective. The most critical locations are:

**Your router's outbound interface.** This is where traffic leaves your network and enters your internet connection. Because your internet link is almost certainly slower than your internal network, this is where congestion is most likely to occur. Prioritizing voice traffic at this point ensures that voice packets are the first to be sent across your internet link during [busy periods](/blog/afternoon-call-quality).

**Managed switches.** If your voice devices and data devices share the same switches, configuring the switches to prioritize voice traffic prevents internal congestion from affecting calls. This matters most in environments where internal traffic volumes are high.

**Access points.** If any VoIP devices are on [wireless](/blog/wired-vs-wifi-for-voip) (which, as we discussed in [Part 6](/blog/your-local-network), should be avoided when possible), enabling wireless multimedia extensions on the access point gives voice traffic priority over the air interface.

## What Quality of Service cannot do

Quality of Service has important limitations that the VoIP industry tends to gloss over.

**Its guarantees stop at your administrative boundary.** Once your packets enter your ISP's network, your DSCP markings may be remarked, ignored, or occasionally carried onward -- but you have no control over which. The prioritization you configured applies only within your own equipment. Whatever happens on the internet leg of a VoIP call gets no dependable benefit from your QoS configuration.

**It cannot create bandwidth.** If your internet connection is 50 megabits per second and you have 60 megabits per second of traffic trying to leave, Quality of Service determines which traffic gets priority, but it cannot make the link faster. If total demand consistently exceeds capacity, you need a bigger pipe.

**It buries the canary.** This is the most underappreciated problem with QoS. Congestion is a signal. When voice quality degrades during busy periods, that degradation is telling you something: your network cannot handle the load. QoS masks that signal by keeping voice clean while everything else suffers. The calls sound fine, so nobody investigates, but the underlying congestion remains. The file transfers slow down, the cloud apps lag, and eventually the congestion grows beyond what QoS can hide. By the time voice quality degrades on a QoS-enabled network, the problem is usually far worse than it would have been if you had caught it early.

**It cannot fix a bad network.** Quality of Service prioritizes traffic within a functioning network. It does not compensate for faulty hardware, misconfigured routing, or physical layer problems. If your switch is dropping packets due to a hardware defect, Quality of Service will not help.

**It requires correct configuration.** Misconfigured Quality of Service can make things worse. If the wrong traffic is marked as high priority, or if the priority queue's bandwidth cap is set too high, the system can create the very problems it was meant to solve.

## The practical recommendation

The right question is not how big your office is -- it is where your actual bottleneck sits. QoS earns its keep at links that genuinely congest, and for most networks that means the WAN egress: the point where a fast LAN funnels into a much slower internet uplink. A one-person office on an asymmetric connection with a thin uplink can get real, measurable benefit from smart queue management (SQM) on the router, because a single large upload can saturate that uplink and bloat its buffers. Conversely, an uncongested 200-person LAN with gigabit switching may not need special queuing at every port, because its internal links never fill.

So diagnose before you configure. If your calls sound bad in the afternoon, find the congested link first. If it is the internet uplink, queue management there (SQM or a voice priority queue) is exactly the right fix. If total demand consistently exceeds the uplink's capacity, you need a bigger pipe -- QoS cannot create bandwidth. And if the culprit is a cloud backup running during business hours or a consumer-grade router that cannot keep up, fix that root cause rather than papering over it. QoS applied without a diagnosis hides symptoms; QoS applied at a measured bottleneck solves them.

If you do configure QoS, the essentials are straightforward: verify your phones are marking packets with DSCP 46 (most do by default), configure your router's outbound interface to prioritize that marking, and enable QoS on your managed switches. After configuring, run a [VoIP quality test](/tools/voip-test) during peak hours to verify that voice traffic is actually getting the priority treatment you expect, and use the [bandwidth calculator](/tools/bandwidth-calculator) to confirm your connection has enough total capacity for your call volume. But treat QoS as insurance for traffic spikes, not as a substitute for a network that is properly sized for its workload.

## What comes next

In the final post of the series, we bring everything together. You now understand how networks work, how voice travels over them, what can go wrong, and how to protect your local network. The last step is learning how to figure out where the problem actually is when things go wrong, which is exactly what VoIP Test is being built to do.

---

*This is Part 9 of the [VoIP From the Ground Up](/blog?category=fundamentals) series. [Part 10: How to Tell Where the Problem Actually Is](/blog/diagnosing-voip-problems) is the capstone, tying everything together into a practical diagnostic framework.*

---

### Part 10: How to Tell Where the Problem Actually Is

URL: https://voiptest.com/blog/diagnosing-voip-problems
Published: 2026-03-25
Tags: voip-fundamentals, diagnostics, troubleshooting

*VoIP From the Ground Up: Part 10 of 10*

This is the post the entire series has been building toward.

You now understand how [traditional phone calls worked](/blog/how-does-a-phone-call-actually-work) and why we moved away from them. You know how [data networks operate](/blog/what-is-a-network), how [packets move](/blog/how-data-moves-in-packets), and [why voice is uniquely sensitive](/blog/why-voice-is-hard) to network imperfections. You understand the difference between the [local network you control](/blog/your-local-network) and the [internet you do not](/blog/the-internet-path). You know what [latency, jitter, and packet loss](/blog/latency-jitter-packet-loss-details) are, how they interact, and how [Quality of Service](/blog/quality-of-service-explained) can protect voice traffic on your side of the boundary.

The question that remains is the one that drove us to build VoIP Test in the first place: when calls [sound bad](/blog/choppy-robotic-audio), how do you figure out where the problem actually is?

## The diagnostic mindset

The first thing to understand is that VoIP troubleshooting is a process of elimination. The voice path has multiple segments, and the problem could be in any one of them. Jumping to conclusions without data leads to the same circular blame game we described in [Part 7](/blog/the-internet-path).

Instead, the goal is to systematically narrow down where in the path the degradation is occurring. You work from the inside out: start with what you control, verify it is clean, and then move further along the path until you find the segment where the numbers go bad.

## Segment 1: The endpoint

Start with the device itself. Is the problem isolated to one phone, one headset, or one computer running a softphone application? If other devices on the same network are experiencing clean calls, the issue may be the endpoint hardware, its configuration, or its connection to the network.

Check the obvious things first. Is the device on a [wired connection or wireless](/blog/wired-vs-wifi-for-voip)? If wireless, move it to wired temporarily and see if the problem resolves. Is the device's network port running at the expected speed, or has it negotiated down to a slower rate because of a cable issue? Is the device's software up to date? Is its codec configuration consistent with what the VoIP provider expects?

A surprising number of quality complaints trace back to a single bad cable, a headset with a failing microphone, or a softphone application running on a laptop that is simultaneously processing heavy workloads. The symptom itself narrows the search too: [echo](/blog/echo-on-voip-calls) and [static, buzzing, or humming](/blog/static-buzzing-humming) usually point at the endpoint, its wiring, or the analog parts of the path rather than the network.

## Segment 2: The local network

If the problem affects multiple devices, the local network is the next suspect. This is where the knowledge from [Part 6](/blog/your-local-network) and [Part 9](/blog/quality-of-service-explained) becomes practical.

Run a latency and [jitter](/blog/what-is-jitter-and-why-it-matters) test between your VoIP devices and your router. On a healthy local network, latency from any device to the router should be no more than a few milliseconds on a wired connection, and jitter should be negligible. (Readings of 1 to 3 milliseconds are normal even on a healthy LAN, because the router answers pings from its slower control plane, the same effect that makes traceroute hops look worse than they are, as covered below.) If you see latency in the tens of milliseconds or measurable jitter on a wired connection, something is wrong with your switching, cabling, or network configuration.

Check for bandwidth saturation. Monitor your network utilization during the time periods when calls sound bad. If your internet link is running at or near capacity during those times, local congestion is likely the cause. This is where Quality of Service makes the biggest difference, but it only works if it is configured correctly.

Look at your switch port statistics if you have managed switches. Error counters, collision counters, and discard counters all tell a story. Rising error counts on a specific port often indicate a cable problem. Rising discard counts indicate congestion.

If your local network checks out clean, the problem is beyond your boundary.

## Segment 3: The internet connection

The boundary between your network and your internet service provider is the most important diagnostic point. This is where you transition from the infrastructure you control to infrastructure you pay for but cannot directly manage.

Test the connection between your router and your internet service provider's first hop. If you see [packet loss](/blog/understanding-voip-packet-loss) or high jitter at this first hop, the problem is either in your internet connection itself or at your provider's local equipment. This is something your internet service provider can investigate, and having specific data showing loss at their first hop gives you something concrete to report.

Also compare your actual bandwidth to what you are paying for. Not in a single speed test, but measured over time during the hours when calls are problematic. Throughput on [business internet connections](/blog/dedicated-internet-access) can vary across the day, though a large peak-hour shortfall is the exception rather than the norm: [the FCC's fixed broadband measurements](https://data.fcc.gov/download/measuring-broadband-america/2023/2023-Fixed-Measuring-Broadband-America-Report.pdf) found most ISP configurations held or beat their advertised download speed even at peak, with DSL the consistent underperformer. What varies much more under load, and what actually matters for voice, is latency and jitter, which a throughput figure does not capture. This sustained measurement is far more useful than a one-time speed test.

## Segment 4: The middle of the internet

This is the hardest segment to diagnose because you have the least visibility into it. Between your internet service provider and your VoIP provider, your traffic may cross several networks, and you cannot directly monitor any of them.

Traceroute is the traditional tool for this. It shows you each hop along the path and the latency to each one. The key rule for reading the output: latency or loss at an intermediate hop only means something if it persists at every hop after it, all the way to the destination. A hop that shows 40% loss followed by clean hops is almost always a false positive, not a problem.

The reason is that traceroute has significant limitations for voice diagnostics. It uses a different type of traffic than VoIP, and routers treat probes aimed *at* them very differently from packets they forward *through* them. Responding to a probe is low-priority housekeeping for a router's control plane, and [most routers deliberately rate-limit those responses](https://www-sop.inria.fr/members/Chadi.Barakat/ICC2015.pdf). So a hop can look slow or lossy in traceroute while forwarding your actual voice packets perfectly. If a latency jump or loss appears at one hop and carries through every subsequent hop to the end of the path, that transition point is a genuine suspect. If it appears at one hop and vanishes at the next, ignore it.

More importantly, even if traceroute identifies the problem hop, you usually cannot do anything about it directly. The device belongs to a network you have no relationship with. The actionable step is to present this data to either your internet service provider or your VoIP provider, depending on whose network is closest to the problem hop, and ask them to investigate.

## Segment 5: The VoIP provider

The final segment is your [VoIP provider's own infrastructure](/blog/sip-trunking). If the path to their network is clean but calls still sound bad, the issue may be on their end: overloaded servers, misconfigured routing, or capacity problems in their data centers.

Most VoIP providers offer some level of call quality metrics in their management portal. Call detail records often include jitter, loss, and [MOS score](/blog/understanding-mos-scores) data for each call, typically gathered from the endpoints' own RTP statistics (RFC 3550) and extended reports like RTCP XR ([RFC 3611](https://www.rfc-editor.org/rfc/rfc3611.html)). These reflect what the media stream actually experienced, which makes them far more trustworthy than ICMP probes. Comparing the metrics they report with what you measure on your end can reveal discrepancies that point to problems within their infrastructure.

If the provider claims their metrics show clean calls but your end is clearly experiencing degradation, the problem is most likely in the path between you, not at either endpoint. This is the hardest scenario to resolve because it requires cooperation between multiple parties who may not have a direct relationship with each other.

## Putting it together

The diagnostic process, simplified:

Check the endpoint first. Rule out device-specific problems by testing with different hardware or connections.

Verify the local network. Confirm that latency, jitter, and loss between devices and the router are within acceptable limits. Verify Quality of Service is configured and functioning.

Test the internet connection. Measure real bandwidth, latency, jitter, and loss to your internet service provider's first hop during the times when problems occur.

Trace the path to the VoIP provider. Identify latency or loss that persists to the end of the path, note where along the path it starts, and determine which network owns that segment.

Check provider-side metrics. Compare what the VoIP provider reports with what you observe on your end.

At each step, you are either finding the problem or eliminating that segment as the cause. By the time you have worked through all five segments, you know where the issue is. And just as importantly, you have the data to prove it.

## Why this is hard to do on your own

If the process above sounds straightforward in theory but difficult in practice, that is because it is. Each step requires different tools, different expertise, and often different access. Running a traceroute is easy. Interpreting the results correctly, understanding which hops matter, knowing when high latency at a specific hop is meaningful versus an ICMP rate-limiting artifact, that takes experience.

And the most critical gap is sustained monitoring. Network problems are often intermittent. They appear during peak hours, during specific routing conditions, or during congestion events at distant peering points. A single diagnostic test run at a random time might show a perfectly clean path, while the same path was severely degraded an hour earlier when the calls were actually bad.

What is needed is continuous, automated measurement of the voice path that captures the exact conditions during quality events. Measurement that simulates actual voice traffic rather than relying on generic network probes. Measurement that covers every segment from your device to the VoIP provider, so when a problem occurs, the data is already there narrowing down where it happened.

Our [VoIP quality test](/tools/voip-test) is the starting point: it measures the end-to-end path using realistic voice traffic patterns, giving you the latency, jitter, and loss numbers that anchor the process above. Like any single-vantage-point test, it cannot by itself isolate every segment of the path -- that is what the elimination process is for -- but it tells you definitively whether degradation exists and how bad it is. For a systematic way to run these measurements (baseline tests, loaded tests, and before-and-after comparisons), see [how to get real numbers instead of "calls sound bad"](/blog/voip-quality-testing-guide).

## The end of the blame game

The entire series has been about building understanding from the ground up so that when voice quality problems happen, you are not helpless. You understand what is going on, you know what to check, and you have a framework for systematically finding the answer.

But understanding the problem is only half the battle. Having the data to prove it, to your internet service provider, to your VoIP provider, to whoever owns the segment that is failing, is what actually gets things fixed.

Independent, continuous, data-driven voice quality analysis that shows exactly where the breakdown is happening and gives every party in the chain the evidence they need to take action. That is the product we are building, and now you understand exactly why it needs to exist.

If you want to be notified when we launch, [sign up on our homepage](https://voiptest.com).

---

*This is the final post in the [VoIP From the Ground Up](/blog?category=fundamentals) series. For deeper dives into specific topics, check out our other posts on [jitter](/blog/what-is-jitter-and-why-it-matters), [packet loss](/blog/understanding-voip-packet-loss), [MOS scores](/blog/understanding-mos-scores), [wired vs. wireless](/blog/wired-vs-wifi-for-voip), and [VoIP quality for remote teams](/blog/voip-quality-for-remote-teams).*

---

## Series: Getting the Internet Right

A 12-part plain language guide to business internet for people who just want their phones to work. Connection types, SLAs, redundancy, and how to choose the right provider.

### Part 1: Your ISP Is the Foundation Everything Else Sits On

URL: https://voiptest.com/blog/isp-foundation
Published: 2026-03-26
Tags: isp-selection, business-internet, voip-troubleshooting

*Getting the Internet Right: Part 1 of 12*

There's a conversation that happens in offices all over the country, usually on a Monday morning, usually after someone important had a bad call on Friday. It goes something like this:

"The phones sounded terrible again. Call the phone company."

So someone calls the VoIP provider. The VoIP provider runs their diagnostics, sees packet loss and jitter in the call logs, and says something like, "Looks like a network issue on your end. You should talk to your internet provider."

So someone calls the ISP. The ISP checks the connection, confirms the circuit is up, speed test looks fine, and says, "Everything looks good from our side. Might be your phone system."

And now you're stuck in the middle, paying two companies that are both telling you the problem belongs to the other one. If this sounds familiar, you're not alone. It is one of the most common frustrations we hear from businesses dealing with call quality issues. And while the [VoIP From the Ground Up](/blog/how-does-a-phone-call-actually-work) series covers how voice traffic works and how to diagnose problems at the VoIP layer, there's a more fundamental question that often gets skipped entirely:

Is your internet connection actually the right fit for what you're asking it to do?

That's what this series is about. Not just "do you have internet" but "do you have the right kind of internet, from the right provider, with the right terms, for the way your business actually uses it." Because the answer to that question affects everything that sits on top of it, from your phones to your cloud apps to your ability to do a video call without looking like you're transmitting from 1997.

## Why the connection type matters more than the speed number

Most people shop for internet the same way they shop for it at home. They look at the speed number, maybe compare prices, and pick whatever seems like the best deal. For home use, that approach mostly works. You're streaming Netflix, browsing the web, maybe working from home a couple days a week. If it feels fast enough, it's probably fine.

Business internet is a different situation, and the reasons why are worth understanding even if you never plan to become a networking expert.

The first thing to know is that the speed number on your bill, the "up to 500 Mbps" or whatever it says, tells you almost nothing about how your connection will perform for voice and video. Speed is about volume. It tells you how much data you can move in a given second -- necessary capacity, but an incomplete measure of quality. And voice calls don't need much volume at all. A single phone call uses somewhere around 80 to 100 kilobits per second in each direction (a typical G.711 call on a 20-millisecond packet interval works out to roughly 87 kbps per direction once packet overhead is counted). That's a tiny fraction of even a slow connection.

What voice calls do need is consistency. They need packets to arrive on time, in order, without gaps. A connection that delivers 500 Mbps in bursts but has moments where packets stall for 200 milliseconds is great for downloading files and terrible for phone calls. The download finishes just as fast either way, but the phone call sounds like the other person is talking underwater.

This is the core reason why "we have fast internet" and "our phones sound bad" can both be true at the same time. They're measuring different things.

## The variables that actually affect your day

If speed isn't the whole picture, what is? There are a few things that matter a lot more than most people realize when it comes to business internet, especially if you're running phones over it.

**Latency** is the time it takes for data to travel across the network. It gets quoted two ways, and it pays to notice which one you're looking at: one-way latency (office to destination) and round-trip latency (there and back, which is what a ping test reports and is roughly double the one-way figure). For web browsing, you'd never notice the difference between 20 milliseconds and 100 milliseconds of round-trip latency. For a phone call, you absolutely will. High latency creates that awkward delay where both people start talking at the same time because neither one can tell when the other has stopped. The common planning guideline, from ITU-T G.114, is that anything over about [150 milliseconds one way starts to feel unnatural](/blog/latency-jitter-packet-loss-details) -- a planning boundary rather than a hard cutoff, but a useful one.

**[Jitter](/blog/what-is-jitter-and-why-it-matters)** is the variation in that latency over time. If your packets take 20 milliseconds to arrive, then 80, then 15, then 120, that inconsistency is jitter. Your phone system has a buffer that tries to smooth this out, but there's only so much it can do. High jitter is one of the most common causes of choppy, robotic sounding audio.

**[Packet loss](/blog/understanding-voip-packet-loss)** is exactly what it sounds like. Some percentage of the data you send or receive just never makes it. For most internet activity, this is invisible because the system just requests the missing pieces again. But voice is happening live. There's no time to ask for a do over. If packets carrying a chunk of someone's sentence get dropped, that chunk is just gone. You hear a gap, or a glitch, or nothing at all.

**Contention** is a concept most people have never heard of, but it might be the most important one on this list. It refers to how much of your capacity you are competing for with other customers. Some services are best effort and contend for shared capacity by design, meaning your neighbors' usage directly affects yours. Others, dedicated internet access being the main example, commit a specific rate to you between defined measurement points, backed by an SLA. Note what that commitment is and is not: it is a promise about the service you receive, not a claim that no infrastructure anywhere is shared, since the access may still be physically or logically aggregated with other customers. The meaningful difference is the committed rate and the remedy behind it, and it is one of the main things separating business grade internet from residential even when the speed numbers look identical.

## Your ISP choice is a business decision, not a tech decision

Here's the thing that gets lost in all the technical talk: choosing an internet provider is fundamentally a business decision. It affects whether your employees can do their jobs without interruption. It affects whether your customers hear clear audio when they call you or whether they hear gaps and echoes. It affects whether your cloud applications work reliably or freeze up at random times during the day.

And yet most businesses spend more time choosing their office coffee supplier than they do evaluating their internet connection. That's not an exaggeration. The typical process goes like this: somebody googles "business internet" plus their city name, calls whatever comes up first, picks a plan that seems fast enough, and moves on. The decision takes maybe 30 minutes, and then it shapes the daily experience of everyone in the office for the next two or three years until the contract is up.

The reason this happens is understandable. Internet service is confusing. The terminology is dense. Providers don't make it easy to compare apples to apples. And frankly, unless something is obviously broken, most people assume their internet is fine. It's only when the phones start acting up, or the video calls keep dropping, or the cloud backup takes 14 hours instead of 2, that anyone starts asking whether maybe the connection itself is the problem.

## What this series will cover

Over the next eleven posts, we're going to walk through everything you need to know to make a genuinely informed decision about your business internet. Not at an engineering level, because you don't need that. At a "I understand what I'm buying and why it matters" level.

We'll start with how internet connections actually work at a basic level, so you have a mental model for understanding why different connection types behave differently. Then we'll go through each major connection type one by one: DSL, cable, fiber (and why not all fiber is the same), dedicated internet access, fixed wireless, and satellite. Each one has specific strengths, specific weaknesses, and specific situations where it's either a great fit or a terrible one.

After that, we'll get into the business side of the equation. We'll cover SLAs (the contract language that determines what happens when things go wrong), redundancy and failover (what it looks like to have a backup plan for your internet), how to actually read an ISP quote without getting buried in jargon, and finally, how to put all of this together into a decision that makes sense for your specific situation.

The goal is not to turn you into a network engineer. The goal is to give you enough understanding that when your internet provider tells you something, or when your VoIP provider points at the connection as the problem, you can evaluate those claims for yourself instead of just taking someone's word for it.

Because the internet connection underneath your business is the foundation that everything else sits on. Your phones, your email, your cloud storage, your video conferencing, your point of sale system, your security cameras, your everything. When that foundation is solid, all of those things work and you never think about it. When it's not solid, you spend your time playing referee between vendors who all insist the problem isn't on their end. If you want a quick baseline measurement of how your current connection handles voice traffic, our [VoIP quality test](/tools/voip-test) can give you concrete numbers to start from.

Let's make sure you have a solid foundation.

---

*Next up: [How Internet Connections Actually Work](/blog/how-internet-connections-work), a plain language explanation of what's actually happening when data moves from your office to the rest of the world.*

---

### Part 2: How Internet Connections Actually Work

URL: https://voiptest.com/blog/how-internet-connections-work
Published: 2026-03-27
Tags: isp-selection, business-internet, networking-basics

*Getting the Internet Right: Part 2 of 12*

Before we start talking about DSL versus cable versus fiber versus everything else, it helps to have a basic mental model for what's actually happening when your office connects to the internet. You don't need to understand this at an engineering level. But having even a rough picture of how data moves makes it much easier to understand why different connection types behave so differently, and why some problems that seem mysterious are actually pretty straightforward once you see the plumbing.

If you read the first post in this series, [Your ISP Is the Foundation Everything Else Sits On](/blog/isp-foundation), you already know that speed isn't the only thing that matters and that consistency is what makes or breaks voice and video. This post is about understanding why some connections are consistent and others aren't, by looking at what's physically happening between your office and the rest of the internet.

## The physical part: getting data from here to there

At the most basic level, your internet connection is a physical thing. It's a wire, or a beam of light, or a radio signal, or a signal bounced off a satellite. Something has to physically carry your data from the equipment in your office to the equipment your internet provider operates, and from there to the broader internet.

The type of physical medium matters a lot. Copper wire behaves differently than fiber optic cable, which behaves differently than a wireless signal. Each one has different characteristics when it comes to how much data it can carry, how far it can carry it before the signal degrades, and how susceptible it is to interference from the environment.

Think of it like plumbing, because that analogy actually holds up surprisingly well. The pipe connecting your building to the water main could be a half inch copper pipe, a two inch PVC pipe, or a six inch main line. They all carry water. But the diameter of the pipe, the material it's made of, and the pressure behind it all determine how much water you can actually get at any given moment, and whether the flow is steady or whether it sputters when your neighbor turns on their sprinklers.

Internet connections work on a similar principle. The physical medium determines the theoretical maximum capacity. But what you actually experience depends on a bunch of factors beyond just the raw capacity of the wire or signal.

## The last mile: where most of the action is

You'll sometimes hear the phrase "last mile" in conversations about internet service. This refers to the connection between your building and your ISP's nearest facility, which is usually called a central office, a headend, or a point of presence depending on the type of provider. Despite the name, it's not always a mile. It could be a few hundred feet or it could be several miles.

The last mile is where most of the interesting stuff happens, and it's where most connection types differ from each other. Once your data reaches your ISP's facility, it gets handed off to their backbone network, which is typically a large, fast fiber network that connects to the broader internet. That backbone is usually not the bottleneck. The last mile is.

This is why two businesses in the same city, paying similar prices, can have wildly different internet experiences. One office might be 500 feet from a fiber node. Another might be three miles from the nearest central office, connected by aging copper that was installed in the 1970s. The backbone they both connect to might be identical. But the last mile makes all the difference.

## Shared versus dedicated: the fundamental split

If there's one concept from this entire series that you take away and remember, it should be this one: the difference between shared and dedicated connections.

A shared connection means that the capacity between your ISP's facility and your neighborhood (or building, or block) is split among multiple customers. Cable internet is the classic example. There's a certain amount of bandwidth available on the cable running down your street, and everyone connected to that cable is sharing it. When it's 2 AM and nobody else is using it, you might get blazing fast speeds. When it's 2 PM and every business on the block is running video calls and cloud backups simultaneously, you're all competing for the same capacity.

A dedicated connection means the provider commits the rate you purchased to your circuit, within its stated service domain, and backs that commitment with an SLA. If you're paying for 100 Mbps dedicated, you get 100 Mbps at 2 AM and you get 100 Mbps at 2 PM on the busiest day of the year. The consistency is dramatically different.

Two honest caveats about what "dedicated" is promising. First, it is a service commitment rather than a claim of physical exclusivity: the provider may still aggregate your traffic with other customers' across shared fiber, ports or equipment, and that is fine as long as the committed rate is delivered between the agreed measurement points. Second, the commitment stops at the edge of the provider's domain. Once your traffic leaves for the broader internet it crosses peering points and other networks shared by everyone, and no product removes that. What a dedicated connection does is eliminate *contention for your committed rate* on the segment where contention most often bites.

This distinction is the single biggest factor in whether a connection will reliably support voice and video. Remember from the last post: voice doesn't need much bandwidth, but it needs that bandwidth to be available consistently, with low latency, low jitter, and minimal packet loss. Shared connections can deliver that sometimes. Dedicated connections deliver that almost always. The price difference reflects this, and we'll get into specific numbers when we cover each connection type in later posts.

## How data actually travels: packets and routing

You've probably heard the word "packets" before, especially if you've read the [VoIP From the Ground Up](/blog/how-does-a-phone-call-actually-work) series. Here's the simple version.

When you load a webpage, make a phone call, or send an email, the data doesn't travel as one continuous stream. It gets broken up into small chunks called [packets](/blog/how-data-moves-in-packets). Each packet contains a piece of the data plus some addressing information that tells the network where it needs to go. Each packet is routed independently and gets reassembled at the destination -- though in practice, routers steer all the packets of one flow (one call, one download) along the same path, so different paths show up between flows or when routes change, not packet by packet within a call.

For most internet activity, this system works beautifully. If a packet gets lost, the receiving end just asks for it again. If packets arrive out of order, they get sorted back into the right sequence. You never notice any of this because it happens in fractions of a second.

Voice traffic is the exception. As we covered in the VoIP series, voice calls happen in real time. When a packet carrying a piece of someone's sentence gets lost or delayed, there's no time to request it again. That piece of audio is simply gone. This is why voice is so much more sensitive to network conditions than regular web browsing or email. It's not that voice needs more from the network. It's that voice can't tolerate the kinds of hiccups that everything else handles invisibly. A [VoIP quality test](/tools/voip-test) measures exactly this: whether your connection delivers packets consistently enough for real-time voice.

## The equipment chain: more links than you think

Between your desk phone (or your computer running a softphone) and the person you're talking to, there are more pieces of equipment involved than most people realize. Understanding this chain helps explain why troubleshooting can be so frustrating, and why your ISP and your VoIP provider can both technically be telling the truth when they say the problem isn't on their end.

Starting from your desk and working outward, the chain looks something like this:

Your device connects to your local network switch or [WiFi access point](/blog/wired-vs-wifi-for-voip). That connects to your router. Your router connects to your modem, or in some setups the router and modem are the same box. The modem connects to whatever physical medium your ISP uses to reach their network, whether that's a copper pair, a coaxial cable, a fiber strand, or an antenna. From there, the signal hits your ISP's equipment at their nearest facility. From that facility, it travels across the ISP's backbone to an interconnection point where it gets handed off to the broader internet. Then it travels across potentially several more networks before reaching the destination.

A problem at any point in this chain can cause issues. A failing network switch in your office closet can cause packet loss that looks exactly like an ISP problem. A degraded copper pair between your building and the central office can cause jitter that looks exactly like a VoIP configuration problem. An overloaded interconnection point between your ISP and the VoIP provider's network can cause latency that neither one of them sees on their own internal monitoring.

This is the "blame game" problem that the [voiptest.com](https://voiptest.com) homepage talks about. When something goes wrong, it's genuinely difficult to figure out which link in the chain is the weak one, because each provider can only see their own piece. Understanding that this chain exists, and roughly where the boundaries fall between what's yours, what's your ISP's, and what's your VoIP provider's, puts you in a much better position to have productive conversations when things go sideways.

## Symmetrical versus asymmetrical: why upload matters

One more concept before we move on to specific connection types. Most residential internet connections, and many business connections, are asymmetrical. That means the download speed (data coming to you) is much faster than the upload speed (data going from you to the internet).

This makes sense for typical home internet usage. You're mostly consuming content: loading web pages, streaming video, downloading files. You rarely need to push large amounts of data in the other direction. A connection that gives you 300 Mbps down and 10 Mbps up works fine for that pattern.

Business use is different. Phone calls are a two way conversation, which means you're sending just as much voice data as you're receiving. Video conferencing is the same. Cloud backups are almost entirely upload. If your business has security cameras uploading footage, a point of sale system syncing transactions, employees working on shared documents in the cloud, or a server that external users need to connect to, the upload direction matters just as much as the download.

A lot of call quality problems come down to this asymmetry. The business has plenty of download speed, so speed tests look great. But the upload is congested during business hours because there simply isn't enough upload capacity for everything that needs it. And since most speed test tools emphasize download speed, the upload bottleneck often goes undiagnosed until someone specifically looks for it.

When we look at each connection type in the following posts, pay attention to whether the speeds are symmetrical or asymmetrical. It's one of the most practical differences between them, and it directly affects how many simultaneous voice and video calls your connection can reliably support.

## Setting the stage

Now you have the basic framework. You know that the physical medium matters, that the last mile is where most variability happens, that shared and dedicated connections are fundamentally different things, that voice traffic is especially sensitive to inconsistency, and that upload speed is just as important as download for business use.

With that foundation in place, we're ready to start looking at specific connection types. We'll begin with the oldest one still in use.

---

*Next up: [DSL: The Connection That Outlived Its Welcome (Sometimes)](/blog/dsl-connection), what it is, where it still works, and where it's holding your business back.*

---

### Part 3: DSL: The Connection That Outlived Its Welcome (Sometimes)

URL: https://voiptest.com/blog/dsl-connection
Published: 2026-03-28
Tags: isp-selection, dsl, business-internet

*[Getting the Internet Right](/blog/isp-foundation): Part 3 of 12*

DSL stands for Digital Subscriber Line, and if you've been in business long enough, there's a decent chance you've used it at some point. It was the first widely available "always on" internet connection for most of the country, replacing dial up in the early 2000s and giving businesses their first taste of internet that didn't tie up the phone line. Twenty plus years later, DSL is still available in a lot of areas, and some businesses are still running on it, either because nothing better is available or because nobody has revisited the decision since the connection was first installed.

Whether DSL still makes sense for your business depends entirely on your specific situation. Let's look at how it works and what the real world implications are.

## How DSL actually works

DSL uses the same copper telephone wires that have been running to buildings since the mid twentieth century. The technology works by splitting the frequency range of the copper pair into channels: the lower frequencies carry your traditional voice calls, and the higher frequencies carry data. This is why DSL originally didn't interfere with your phone service. The two could coexist on the same wire.

The data signal runs from your building through the copper pair to a piece of equipment at your phone company's central office called a DSLAM, which stands for Digital Subscriber Line Access Multiplexer. The DSLAM aggregates all the DSL connections in your area and connects them to the phone company's backbone network. From there, your traffic reaches the broader internet.

The important thing about this setup is that your copper pair, the actual wire between your building and the central office, is yours. Nobody else is sharing that specific physical pair. This makes DSL a dedicated connection at the last mile level, which is one of its advantages over cable internet. Your neighbor's usage doesn't directly affect your speeds.

However, the capacity of DSL is limited by physics, and this is where the problems start.

## The distance problem

Copper wire is not a great medium for high frequency data signals. The signal degrades as it travels along the wire, and it degrades faster at higher frequencies. This means that the further your building is from the central office, the slower your DSL connection will be. This isn't a "might be slower" situation. It's a mathematical certainty based on the physical properties of copper.

A business located a few thousand feet from the central office might get 20 to 40 Mbps on a good DSL technology like VDSL2. Those are field figures, not specification limits: [VDSL2 is specified](https://www.itu.int/dms_pubrec/itu-t/rec/g/T-REC-G.993.2-201902-I!!SUM-HTM-E.htm) for bidirectional rates up to 200 Mbps over 30 MHz of spectrum, and almost nothing in the ground delivers that. A business three miles away might get 3 to 5 Mbps. A business five miles away might not be able to get DSL at all, or might be stuck at speeds so low they're barely functional.

The phone company can tell you how far you are from the central office, but many don't volunteer this information unless you specifically ask. And because the wire doesn't run in a straight line, the actual cable distance is often significantly longer than what you'd measure on a map. The wire follows streets, goes through junction boxes, and may take a circuitous route that adds considerable length.

This distance sensitivity is DSL's defining limitation. Unlike cable or fiber, where the technology can deliver similar speeds to most customers in a service area, DSL performance varies enormously from building to building within the same neighborhood. Two offices on the same street can have very different experiences if one is closer to the central office than the other.

## The speed ceiling

Even under ideal conditions, with a short copper run and modern equipment on both ends, DSL tops out at speeds that feel increasingly inadequate for business use. Standard ADSL maxes out around 8 Mbps download, and [ADSL2+](https://www.itu.int/dms_pubrec/itu-t/rec/g/T-REC-G.992.5-200901-P!!SUM-HTM-E.htm) pushes that to around 20 to 24 Mbps download and about 1 Mbps upload, or up to roughly 3 Mbps on the upstream-extended variant, which is uncommon in North American deployments. VDSL2 can reach higher, up to 50 or even 100 Mbps at very short distances, but those speeds fall off quickly as distance increases.

More importantly, look at those upload numbers. Even VDSL2 is typically asymmetric, meaning the upload speed is a fraction of the download. As we discussed in [How Internet Connections Actually Work](/blog/how-internet-connections-work), upload speed matters a lot for business use. Phone calls, video conferencing, cloud backups, and file sharing all need upload capacity.

It's worth doing the voice arithmetic explicitly rather than guessing. Using <a href="https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/7934-bwidth-consume.html" rel="nofollow noopener noreferrer" target="_blank">Cisco's voice bandwidth model</a> (codec payload plus RTP/UDP/IP and Layer-2 overhead), a G.711 call with 20 ms packetization consumes roughly 87 kbps in each direction on Ethernet. Five simultaneous calls are about 435 kbps each way. If you reserved 75% of a 2 Mbps uplink for voice, the arithmetic ceiling is roughly 17 concurrent calls before tunnel or access-specific overhead. So voice alone rarely fills a DSL uplink; what actually congests it is everything else sharing the pipe. One cloud backup or a couple of video calls can saturate 2 Mbps on their own, DSL sync rates drift with line conditions, and once the uplink queue fills, every call on it suffers. Our [Bandwidth Calculator](/tools/bandwidth-calculator) can help you estimate the real threshold for your office's mix of traffic.

A thin uplink might be fine for a three person office. It's probably not fine for a fifteen person office: not because the calls themselves outgrow it, but because the video calls, cloud pushes, and backups running alongside them will.

## The reliability question

DSL connections tend to be reasonably reliable in terms of uptime. The copper infrastructure has been in place for decades, and the phone companies generally maintain it to a functional level. But "functional" for voice calls is a very low bar. A copper pair can have minor faults, corroded connections at junction boxes, or water intrusion at splice points that cause no noticeable issue for a voice call but create enough signal noise to cause errors on the data side.

These intermittent issues are particularly frustrating because they can come and go. Your connection might work perfectly fine for two weeks, then have a bad day where latency spikes and packet loss increases, then go back to normal. The copper is more susceptible to interference when it's wet, so these problems often correlate with rainy weather. If you've ever noticed that your call quality seems worse on rainy days, this might be why, and it's not your imagination.

The age of the copper plant varies significantly by area. In some places, the wiring has been updated relatively recently. In others, you're sending data over copper that was installed during the Carter administration. The phone company isn't typically investing in upgrading this infrastructure, because they're focused on building out fiber where it makes economic sense and maintaining the copper only where they're required to. In fact, the copper is now on borrowed time: [AT&T has stopped taking new copper orders and aims to exit most of its copper footprint by the end of 2029](/blog/pots-copper-shutdown-2026) (its own target rather than a regulatory deadline, and one that excludes California, where the retirement is still contested), and DSL rides the same copper plant as the POTS lines being retired.

## Where DSL still makes sense

Despite its limitations, there are situations where DSL is a reasonable choice.

If you're a small office in an area where DSL is the best available option, meaning no cable, no fiber, and no fixed wireless, then a DSL connection that delivers consistent speeds at a short distance from the central office can work fine. If your building happens to be close to the central office and you only have a handful of employees, DSL can handle your phone system and basic internet needs adequately.

DSL can also make sense as a backup connection. Because it runs over the copper telephone network, which is physically separate from the cable and fiber networks, a DSL line can provide redundancy against an outage on your primary connection. If your main connection is cable or fiber and it goes down, a DSL backup can keep your phones running and your basic internet accessible until the primary is restored. We'll talk more about this in the [Redundancy and Failover](/blog/redundancy-failover) post later in the series.

## Where DSL doesn't make sense

If you have more than a handful of people in the office, or if you're relying on cloud applications for significant parts of your workflow, DSL is probably not giving you what you need. The upload constraint is not really about the calls themselves (as the arithmetic above shows, voice is lightweight) but about how quickly everything else on a 1 to 3 Mbps uplink congests the queue that those calls depend on.

If your building is more than about two miles from the central office by cable distance, DSL speeds are likely to be disappointing regardless of what the provider's marketing says. Treat every distance figure here as a field rule of thumb rather than a specified limit: no DSL recommendation states a reach ceiling, because the achievable rate depends on the profile, wire gauge, bridged taps, crosstalk and noise margin on your particular pair. The "up to" speeds that DSL providers advertise are best case numbers achieved at close range. They bear little resemblance to what most customers actually get.

If you're experiencing call quality problems on a DSL connection, running a [VoIP quality test](/tools/voip-test) will show you whether the connection itself is introducing the jitter and packet loss that cause audio problems. The connection should be near the top of your troubleshooting list. The combination of limited upload bandwidth, potential copper degradation, and susceptibility to environmental interference makes DSL one of the more common root causes of VoIP issues, especially in offices that have grown since the connection was originally installed. What worked for a two person office five years ago may not work for an eight person office today.

## The honest take

DSL was a great technology for its time. It gave millions of businesses their first usable internet connection and served that purpose well for years. But the demands on business internet have changed dramatically. Cloud computing, VoIP phones, video conferencing, and software as a service applications have all increased what's expected of a connection in ways that DSL mostly can't keep up with.

If you're currently on DSL, it's worth finding out what other options might be available at your address. The landscape has changed a lot in the last few years, with fiber buildouts expanding into areas that previously had no options beyond DSL and cable. You might be surprised at what's available now that wasn't available when your current connection was installed.

If DSL is genuinely your only option, the best you can do is make sure you're on the best DSL technology available to your location, that your copper is in good shape (the phone company can run line quality tests), and that you're managing your usage to stay within the connection's limits. [Prioritizing voice traffic](/blog/quality-of-service-explained) on your router, if your router supports it, can help ensure your calls get the bandwidth they need even when other things are competing for the limited upload.

---

*Next up: [Cable Internet: Fast Until the Neighborhood Wakes Up](/blog/cable-internet), why the speeds look great on paper and the reality is more complicated.*

---

### Part 4: Cable Internet: Fast Until the Neighborhood Wakes Up

URL: https://voiptest.com/blog/cable-internet
Published: 2026-03-29
Tags: isp-selection, cable-internet, business-internet

*Getting the Internet Right: Part 4 of 12*

Cable internet is probably the most common type of business internet in the country right now, and for understandable reasons. It's widely available, the speeds are high, the pricing is reasonable, and for many businesses it works well enough that they never have a reason to look deeper. But "well enough" and "right for your situation" aren't always the same thing, and cable has some characteristics that are worth understanding, especially if you're running phones or video over it.

## How cable internet works

Cable internet uses the same coaxial cable network that delivers cable television. That's the thick round cable with the threaded connector that you've probably screwed into the back of a TV at some point. The technology that makes internet work over these cables is called DOCSIS, which has gone through several generations. The version deployed almost everywhere today, DOCSIS 3.1, supports [up to 10 Gbps downstream and up to 1 Gbps upstream](https://www.cablelabs.com/technologies/docsis-3-1) on paper, but most cable providers deploy it at speeds up to about a gigabit download.

The coaxial cable runs from your building to a neighborhood node, which is typically a cabinet or box mounted on a utility pole or in a ground enclosure somewhere in your area. That node converts the signal and sends it to the cable company's headend facility, usually over fiber. From the headend, you reach the cable company's backbone and then the broader internet.

That neighborhood node is the key piece to understand. Unlike [DSL](/blog/dsl-connection), where each customer has their own dedicated copper pair, cable internet shares the coaxial cable between your building and the node with other customers in your area. Everyone connected to the same node is sharing the same pool of bandwidth.

## The shared bandwidth problem

This is cable's defining characteristic, and it's the source of most of the complaints that people have about it, even if they don't realize it.

When the cable company says you have a "500 Mbps" connection, what they mean is that you can use up to 500 Mbps of the total capacity available at your node. But the total capacity at the node is split among all the customers connected to it. If there are 200 homes and businesses on your node and nobody else is doing anything, you might actually see speeds close to 500 Mbps. If it's midday and half of those connections are active, you're all sharing the same capacity.

In practice, this means your cable internet speeds can vary throughout the day. The typical pattern -- and it is a typical pattern, not a rule; how pronounced it is depends entirely on your provider and how loaded your particular node is -- looks like this: early morning and late night tend to be fast. The middle of the workday is often slower. And the worst period, somewhat counterintuitively, is frequently early evening when residential customers come home and start streaming video, because many business cable connections share infrastructure with the residential network in the same area. A lightly loaded node may show none of this; a saturated one will show it every day like clockwork.

For web browsing and file downloads, this variability is usually just an annoyance. Pages load a little slower, downloads take a bit longer. You probably wouldn't even notice unless you were running a speed test at different times of day.

For voice and video, the story is different. It's not the speed reduction itself that causes problems. As we discussed in [How Internet Connections Actually Work](/blog/how-internet-connections-work), voice calls don't need much bandwidth. The issue is that congestion at the node doesn't just reduce speed. It also increases latency, increases [jitter](/blog/what-is-jitter-and-why-it-matters), and can cause packet loss. These are exactly the three things that voice traffic cannot tolerate.

To take an illustrative example: a cable connection that tests at 300 Mbps during off peak hours and 100 Mbps during peak hours might still have plenty of raw speed for your calls at both times. But the congestion that caused the speed to drop from 300 to 100 may also have pushed your jitter from 5 milliseconds to 40 milliseconds, and that's the difference between crystal clear calls and calls that sound [choppy or robotic](/blog/choppy-robotic-audio). The specific numbers will differ from node to node -- the pattern is what to watch for.

## The upload asymmetry

Cable internet is asymmetrical by design, and severely so; [the FCC's measured upload speeds by technology](https://data.fcc.gov/download/measuring-broadband-america/2021/2021-Fixed-Measuring-Broadband-America-Report.pdf) show the same pattern. A typical cable business plan might offer 500 Mbps download and 20 to 35 Mbps upload. Some plans are even more lopsided than that.

DOCSIS 3.1 allocates the majority of the available spectrum to the download direction because the technology was designed primarily for content consumption, delivering TV and video. The upload allocation is a fraction of the download, and it's shared among all customers on the node just like the download is.

For businesses running VoIP, this matters a lot. Your calls need upload bandwidth for the outgoing audio, and if you've got ten people on calls simultaneously, that's roughly 1 Mbps of steady upload traffic just for voice with the common G.711 codec (compressed codecs use less). Add in video calls, cloud backup, email with attachments, and anything else that sends data outbound, and that 20 Mbps upload can get tight faster than you'd expect.

This is one of the more common scenarios we see when businesses have intermittent call quality problems. The download speeds look great, the connection seems fast, speed tests come back impressive, but the upload is congested during business hours because there simply isn't enough upload capacity for everything that needs it. Our [Bandwidth Calculator](/tools/bandwidth-calculator) can help you estimate whether your upload capacity is sufficient for your actual call volume and cloud usage. And since most speed test tools emphasize download speed, the upload bottleneck often goes undiagnosed until someone specifically looks for it.

## Business cable versus residential cable

Most cable companies offer both residential and business internet plans. The business plans are more expensive, often significantly so. What do you get for the extra money?

The answer varies by provider, but typically a business cable plan includes a static IP address (important for some business applications), a service level agreement that promises faster response times for outages, the option for a phone line bundled with the service, and sometimes slightly higher upload speeds. Some providers also claim that business customers are on a less congested node, though this isn't always verifiable.

What you generally don't get is a fundamentally different network experience. Business cable still uses the same coaxial infrastructure, the same DOCSIS technology, and in many cases the same neighborhood nodes as the residential service. The shared bandwidth characteristic is still there. You're paying more for better support and better terms, which have real value, but the underlying connection technology is the same.

This is an important distinction. When a cable company tells you they offer "business grade" cable internet, they're not wrong. But they're not describing the same thing as what the telecom industry means by "business grade" in the context of dedicated connections. It's a marketing term being applied to a shared infrastructure product. That doesn't make it bad. It makes it something you should understand clearly before you buy.

## Where cable internet works well

For small to medium businesses with moderate phone usage and good availability in their area, cable internet is a perfectly viable primary connection. If your office has under 15 or 20 people, you're not running a call center, and you're in an area where the cable infrastructure is well maintained and not overly congested, cable can deliver a good experience at a reasonable price.

Cable is also very widely available, which is a real advantage. In many suburban and urban areas, you can get cable internet at locations where fiber isn't available yet. The installation is typically straightforward and fast compared to dedicated connections, which can take weeks or months to provision.

If you're on cable and your experience is consistently good, there may be no reason to change. The important thing is to understand what you have and what its limitations are, so that if problems develop, you know where to look.

## Where cable internet falls short

Cable becomes a harder sell as your office grows, as your dependency on phones and video increases, or as you move into applications that need reliable upload bandwidth. The shared nature of the connection means that problems can appear that are entirely outside your control. A new business moving into the building next door, or a shift in usage patterns in your neighborhood, can change your internet experience overnight without anything on your end changing.

Call centers or any business where phones are a primary tool should think carefully about relying on cable as their sole connection. The variability in quality during peak hours, combined with the upload constraints, creates a risk that dedicated connections simply don't have.

If you're already experiencing intermittent call quality issues on a cable connection, especially if they tend to happen at consistent times of day, congestion on your node is a strong possibility. Running a [VoIP quality test](/tools/voip-test) at different times of day can help you see exactly when jitter and packet loss spike, which is strong evidence to bring to your cable provider. Your cable provider may be able to tell you how loaded your node is, though getting that information sometimes requires persistence. If the node is heavily loaded, the only real fix on the provider's side is a node split, where they divide the customers on an overloaded node into two separate nodes. Providers do this regularly, but it's on their timeline, not yours.

## The DOCSIS 4.0 question

DOCSIS 4.0 is the next generation of cable technology, and it promises to address some of cable's current weaknesses, particularly on the upload side. The new standard raises upstream capacity to as much as 6 Gbps against 10 Gbps downstream ([what DOCSIS 4.0 actually specifies](https://www.cablelabs.com/technologies/docsis-4-0-technology) is faster upload, not equal capacity in both directions), which is enough for operators to sell genuinely symmetrical multigigabit tiers. Some cable companies have announced rollout plans, though widespread deployment is still in its early stages.

If and when DOCSIS 4.0 becomes widely available, it could significantly change the calculus for business cable internet. Symmetrical speeds on a cable connection would remove one of the biggest complaints about the technology for business use. However, the shared bandwidth characteristic would still be there, so congestion during peak hours would still be a factor even with higher upload speeds.

For now, buying decisions should be based on what's actually available and deployed at your address today, not on roadmap promises. When DOCSIS 4.0 is real and in the ground at your location, it'll be worth another look.

---

*Next up: [Fiber Internet: Not All Fiber Is the Same](/blog/fiber-internet), the connection type everyone wants, and the details that determine whether you're actually getting what you think you're getting.*

---

### Part 5: Fiber Internet: Not All Fiber Is the Same

URL: https://voiptest.com/blog/fiber-internet
Published: 2026-03-30
Tags: isp-selection, fiber-internet, business-internet

*Getting the Internet Right: Part 5 of 12*

Fiber internet has become the gold standard that everyone asks for. "Can we get fiber?" is usually one of the first questions a business asks when they're shopping for internet, and for good reason. Fiber optic connections are faster, more reliable, and more consistent than anything running over copper or coaxial cable. But the word "fiber" gets used to describe several very different products, and understanding those differences is important. A business that thinks they're getting one thing and is actually getting another can end up disappointed, overpaying, or both.

## How fiber works

Fiber optic cables transmit data as pulses of light through thin strands of glass. Each strand is about the diameter of a human hair. The light signals can travel long distances with almost no degradation, which is why fiber doesn't have the distance limitations that plague DSL. Not that reach is unbounded (GPON specifies physical reach options of 10 and 20 km), but a fiber run measured in miles performs the same at the far end as at the near one, where DSL degrades over every foot. A fiber connection performs essentially the same whether you're 500 feet from the provider's equipment or five miles away.

The bandwidth capacity of fiber is, for all practical purposes, limited only by the equipment on each end, not by the fiber itself. A single strand of fiber can carry enormous amounts of data. When providers upgrade their networks to support higher speeds, they typically just need to upgrade the electronics at either end. The glass in the ground stays the same. This is why fiber is considered the infrastructure that will serve for decades.

Fiber is also inherently resistant to electromagnetic interference, which means it doesn't pick up noise from nearby electrical equipment, radio signals, or lightning strikes the way copper and coaxial cable can. This contributes to lower error rates and more consistent performance.

All of that sounds great, and it is. But here's where it gets more nuanced.

## The two fundamentally different fiber products

When a provider says they offer "fiber internet," they could be talking about shared fiber (often called best effort fiber, or GPON/EPON) or dedicated fiber. The difference is as significant as the difference between cable and a private leased line.

A word on terminology before we go further, because these get used interchangeably and shouldn't be. "Dedicated fiber" describes the *physical access*: an exclusive strand or wavelength. "DIA" (Dedicated Internet Access) describes a *commercial commitment* (a committed rate with an SLA) and says nothing by itself about the access technology underneath. They frequently arrive together, which is why the terms blur, but they are separate promises and worth checking separately.

**Shared fiber** usually runs over a passive optical network: GPON, standardised by the ITU-T, or EPON, standardised by the IEEE. It is often marketed as "fiber to the premises" or FTTP, though that phrase describes the topology rather than the technology: point-to-point fiber to a building is FTTP too, and is not shared at all. In this setup, a single fiber strand from the provider's equipment is split, using a device called an optical splitter, to serve multiple customers. A typical split ratio is 1 to 32, a deployment convention rather than a specification limit, since [the standard permits splits up to 1 to 64](https://www.itu.int/rec/dologin_pub.asp?lang=e&#x26;id=T-REC-G.984.1-200803-I!!PDF-E&#x26;type=items). That means up to 32 customers share the capacity of a single fiber strand. The total capacity of that shared strand is usually around [2.5 Gbps download and 1.25 Gbps upload for GPON, or 10 Gbps symmetrical for the newer XGS-PON standard](https://www.itu.int/en/ITU-T/studygroups/2017-2020/15/Documents/OFC2021-1-Frank-Effenberger.pdf).

If those numbers sound huge, they are. But remember, that capacity is shared among up to 32 customers. At a 1 to 32 split ratio on standard GPON, the average available bandwidth per customer is about 78 Mbps download and 39 Mbps upload if everyone is using it simultaneously, and roughly half that again on a 1 to 64 split, which is worth asking about. In practice, not everyone uses the connection at the same time, so most customers experience speeds well above those averages most of the time. But the shared nature means that performance can vary, and the provider is typically overselling the capacity, banking on the fact that not everyone will need full speed simultaneously.

Sound familiar? It should. This is the same shared bandwidth model that [cable internet](/blog/cable-internet) uses. Shared fiber is better than cable in several important ways, including higher total capacity on the shared segment, better symmetry between upload and download, and the inherent reliability advantages of fiber over coaxial cable. But it's still shared. During peak usage, you may see reduced speeds and increased latency, just as with cable, though the effect is usually less severe because there's more total capacity to go around.

**Dedicated fiber** is a different product, and the single most useful habit here is to treat it as two separate things that are often, but not necessarily, sold together.

The first is the **physical access**: your own fiber strand or wavelength that nobody else shares, so there's no split ratio and no last-mile contention.

The second is the **service commitment**: a committed information rate (CIR) and a [service level agreement](/blog/sla-contract-language) covering your bandwidth between defined measurement points across the provider's own network. That commitment is what DIA actually names: it describes the contract, not the access technology, and it can be delivered over more than one physical architecture.

Neither implies the other. A provider can sell you an exclusive strand with weak or no service commitment, or sell genuine DIA delivered over an access design that is aggregated somewhere upstream. So when someone quotes you "dedicated fiber," identify the two separately: what exactly is the physical handoff, and what is the CIR and SLA behind it? If you're paying for 100 Mbps symmetrical DIA you should get exactly that, all the time, within the provider's domain. And it's the contract, not the glass, that makes that true.

Dedicated fiber connections are what the industry means when they talk about "business grade" fiber, and they come with characteristics that shared connections don't: guaranteed bandwidth backed by an SLA, symmetrical speeds as standard (upload equals download), and [typically much lower latency and jitter](https://data.fcc.gov/download/measuring-broadband-america/2021/2021-Fixed-Measuring-Broadband-America-Report.pdf) because there's no contention at any point in the last mile. One thing even DIA cannot promise: an unshared path all the way to every destination. Beyond the provider's network, your traffic crosses peering points and the broader internet on shared infrastructure like everyone else's. The CIR and SLA cover the provider's domain, which is where they have control -- and, fortunately, where most contention problems live.

## Why this distinction matters so much

The practical difference between shared and dedicated fiber shows up most clearly in consistency. A shared fiber connection might deliver 800 Mbps during off hours and 200 Mbps during peak, with jitter occasionally spiking during busy periods. Running a [VoIP quality test](/tools/voip-test) at different times of day will reveal whether your fiber connection maintains the consistency that voice traffic needs. A dedicated fiber connection delivering 200 Mbps will deliver 200 Mbps at all times, with consistently low jitter and latency.

For web browsing and file transfers, the shared connection is arguably the better deal. You're getting higher peak speeds for less money. But for voice and video, the dedicated connection is in a different league. Remember, your phones don't need 800 Mbps. They need 1 to 2 Mbps with rock solid consistency. Our [Bandwidth Calculator](/tools/bandwidth-calculator) can help you figure out exactly how much capacity your office needs based on your call volume. The dedicated connection's lower speed number with guaranteed consistency is worth more for voice traffic than the shared connection's higher speed number with variable performance.

This is one of the areas where businesses get confused most often. They see a shared fiber plan offering a gigabit for $150 a month and a dedicated fiber plan offering 100 Mbps for $500 a month, and they can't understand why anyone would pay more for less speed. The answer is that they're buying two completely different products that happen to share the word "fiber" in their names.

## How to tell which one you're being offered

Providers don't always make it easy to tell whether a fiber product is shared or dedicated. Here are some questions that will clarify things quickly:

Is the bandwidth symmetrical? If the plan shows different upload and download speeds, it's almost certainly shared. Dedicated fiber is symmetrical by default.

Does the plan come with an SLA that includes bandwidth guarantees, uptime guarantees, and credits for violations? Dedicated connections come with these. Shared connections typically don't, or they come with very weak ones.

What's the installation timeline? Shared fiber typically installs in days to a couple of weeks, similar to cable. Dedicated fiber can take 30 to 90 days or longer, because it often involves building or provisioning a new circuit specifically for your location.

What's the pricing structure? Shared fiber is priced like cable, usually under $200 a month for most plans. Dedicated fiber starts in the hundreds and can reach thousands per month depending on the bandwidth. If the pricing seems too good to be true for a "dedicated" connection, ask more questions.

Does the contract include a committed information rate (CIR)? This is the bandwidth the provider guarantees you will always have access to. Dedicated connections have a CIR equal to the speed you're paying for. Shared connections either don't have a CIR or have one that's much lower than the advertised speed.

## Shared fiber is still really good

Don't walk away from this post thinking shared fiber is a bad product. It isn't. For most small and medium businesses, shared fiber, where available, is an excellent choice. It offers significantly better performance than cable, typically better upload speeds, better reliability, and it's priced competitively. Many businesses run VoIP over shared fiber without any issues.

The point is not that shared fiber is bad. The point is that it's not the same product as dedicated fiber, and understanding which one you need depends on your specific requirements. A five person office that makes a normal volume of phone calls will be perfectly well served by shared fiber. A 50 person office with heavy phone usage and mission critical cloud applications might need dedicated.

## The availability gap

The biggest challenge with fiber of either kind is availability. Despite aggressive buildouts by major providers over the last several years, fiber is still not available at every business address. Availability varies dramatically by region, by neighborhood, and sometimes by building. The business next door might have fiber available while you don't, because the fiber passes their property but doesn't extend to yours.

Getting fiber to a location that doesn't currently have it can involve construction, which means permitting, trenching, and installation costs that are sometimes passed on to the customer. These construction costs can range from nothing (if the provider is building out the area anyway) to tens of thousands of dollars. This is another area where understanding your options and getting quotes from multiple providers matters a lot.

We'll cover the process of evaluating and comparing ISP quotes in detail in the [Reading an ISP Quote](/blog/reading-isp-quote) post later in this series.

---

*Next up: [Dedicated Internet Access: What You're Actually Paying For](/blog/dedicated-internet-access), a deeper look at the premium product, who needs it, and who doesn't.*

---

### Part 6: Dedicated Internet Access: What You're Actually Paying For

URL: https://voiptest.com/blog/dedicated-internet-access
Published: 2026-03-31
Tags: isp-selection, dedicated-internet, business-internet, dia

*Getting the Internet Right: Part 6 of 12*

If you've been reading this series from the beginning, you've seen the phrase "dedicated connection" come up several times. In the posts on [DSL](/blog/dsl-connection), [cable](/blog/cable-internet), and [fiber](/blog/fiber-internet), we kept drawing the same line: shared connections can be fast and are often affordable, but dedicated connections deliver the consistency that voice and video demand. This post is where we dig into dedicated internet access specifically, what it is, how it works, what you're paying for, and whether it's worth it for your business.

## What Dedicated Internet Access actually means

Dedicated Internet Access, usually abbreviated as DIA, is less a physical thing than a contract construct: a committed information rate (CIR), a defined service demarcation point, and an SLA with remedies. If you buy 100 Mbps of DIA, the provider commits that 100 Mbps is available to you at all times between your demarc and their network edge, regardless of what anyone else in your area is doing. The access circuit isn't oversubscribed the way shared services are. What DIA does not promise is a private fiber strand or an unshared route all the way to every destination: once your traffic leaves the provider's network, it crosses the public Internet like everyone else's. You're buying the committed rate and the accountability around it, and it's worth knowing exactly where those commitments start and stop.

DIA is almost always delivered over fiber, though in some areas it can be delivered over copper circuits like a T1 or a bonded T1 setup, though those are increasingly rare. The fiber version is what most people are looking at today, and it's what we'll focus on here.

The defining characteristics of DIA are:

**Committed bandwidth.** The speed you pay for is the speed you get, all the time, between the defined measurement points, which are [typically your demarc and the provider's network edge](https://www.itu.int/rec/dologin_pub.asp?lang=e&#x26;id=T-REC-Y.1541-201112-I%21%21PDF-E&#x26;type=items). This isn't an "up to" number. It's a [committed information rate](https://www.itu.int/rec/dologin_pub.asp?lang=e&#x26;id=T-REC-G.8011.2-200901-S!!PDF-E&#x26;type=items) backed by the provider's SLA.

**Symmetrical speeds.** Upload and download are the same. If you buy 100 Mbps, you get 100 Mbps in both directions. This is standard for DIA and is one of its biggest advantages for business use.

**[Service Level Agreements](/blog/sla-contract-language) with teeth.** DIA contracts include SLAs that specify uptime targets (commonly 99.9% or higher, a carrier convention rather than a figure any standard sets, so translate it before you sign: 99.9% still permits about 8 hours 45 minutes of downtime a year, where 99.99% permits about 53 minutes), latency targets, packet loss targets, and jitter targets, along with a repair interval and the service credits you get if the provider misses them. These aren't just nice words in the contract. They represent a legal commitment that gives you recourse when things go wrong. Do read the fine print on scope, though: the latency and loss figures are measured between the provider's own measurement points, usually within their network, and they don't govern the public-Internet path beyond their edge. Check whether the latency figure is round-trip or one-way as well: voice transmission planning guidance such as ITU-T G.114 is expressed as one-way delay, so comparing an SLA's round-trip number against it directly overstates your margin by half.

**Prioritized support.** When your DIA circuit has an issue, you don't call the same support number as residential customers. DIA customers typically have dedicated support channels with faster response times and access to engineers, not just front line technicians.

## How DIA pricing works

DIA is significantly more expensive than shared connections, and the pricing structure is different from what most people are used to.

A cable connection might cost $100 to $200 per month for hundreds of megabits of download speed. A shared fiber connection is similar. DIA typically starts around $300 to $500 per month for modest bandwidth, say 50 to 100 Mbps, and scales up from there. High bandwidth DIA, 500 Mbps to a gigabit, can run into the thousands per month.

The pricing also varies significantly by location. DIA in a major metro area where multiple providers have existing fiber infrastructure will be much cheaper than DIA in a rural area where the provider needs to build fiber to reach your building. The same 100 Mbps DIA circuit that costs $400 a month in downtown Dallas might cost $1,200 a month in a small town where only one provider can reach you.

This geographic variability in pricing is one of the reasons that shopping for DIA is more complicated than [shopping for cable or residential fiber](/blog/how-to-choose-isp). It's not as simple as looking at a price list on a website. DIA is typically a custom quote based on your specific address, the providers that have infrastructure nearby, and the bandwidth you need. The pricing can also include installation fees, which may involve construction charges if fiber needs to be extended to your building.

## What you're really buying

The sticker shock on DIA pricing makes more sense when you understand what's included beyond the raw bandwidth.

You're buying consistency. A 100 Mbps DIA connection will typically support more simultaneous VoIP calls with better quality than a 500 Mbps cable connection, because the access circuit gives every one of those calls the bandwidth it needs with [predictable latency and jitter](/blog/latency-jitter-packet-loss-details). Running a [VoIP quality test](/tools/voip-test) on a DIA circuit versus a shared connection during peak hours makes the difference immediately obvious. There's no congestion at 2 PM on your access loop, no degradation during peak hours, no variability based on what businesses next door are doing. The commitment covers the provider's network, not the entire Internet, but the access circuit is where shared connections most often fall down, and that's exactly the segment DIA locks in.

You're buying accountability. The SLA means that when something goes wrong, you have a documented commitment from the provider about how quickly they'll respond and what compensation you'll receive if they don't meet their targets. With shared connections, the provider's obligation is typically limited to "we'll try to fix it." With DIA, the obligation is specific and measurable.

You're buying symmetrical bandwidth. For businesses that rely on voice, video, cloud applications, or any significant amount of outbound data, symmetrical bandwidth eliminates the upload bottleneck that plagues cable and most shared fiber connections.

You're buying a business relationship instead of a consumer transaction. DIA providers understand that their customers are running businesses that depend on the connection. The support experience reflects that understanding.

## Who needs DIA

Not every business needs DIA, and being honest about that is important because overspending on connectivity is just as much of a problem as underspending.

Businesses that should seriously consider DIA include:

Offices with 20 or more employees who are actively using phones and internet simultaneously. At this scale, the consistency of DIA starts to matter a lot because the aggregate demand on the connection is high enough that shared connections may struggle during peak hours. Our [Bandwidth Calculator](/tools/bandwidth-calculator) can help you estimate whether your current connection has enough headroom or whether DIA is warranted.

Any business where phones are a primary revenue tool. Call centers, sales organizations, support teams, legal offices that spend significant time on calls, medical offices scheduling and consulting over the phone. If a bad call costs you money or damages a relationship, the reliability premium of DIA pays for itself quickly.

Businesses running critical cloud applications. If your ERP, your CRM, your EMR, or your primary line of business application is cloud hosted, the consistency of DIA reduces the risk of slowdowns and outages that affect productivity across the entire organization.

Businesses in regulated industries where uptime and documentation matter. Healthcare, financial services, and legal practices often need the SLA documentation that DIA provides, both for compliance purposes and for the operational assurance it represents.

## Who doesn't need DIA

Small offices with under ten people and moderate phone usage are usually well served by a good shared fiber connection, or even cable in areas where the infrastructure is solid. The cost difference between DIA and shared connectivity is significant enough that it doesn't make sense unless you actually need the guarantees.

If your business primarily uses the internet for web browsing, email, and occasional cloud application use, and your phone volume is light, shared connectivity will likely meet your needs at a fraction of the cost.

The key is to be realistic about your actual usage patterns and your tolerance for inconsistency. If an occasional bad call day once a quarter wouldn't meaningfully affect your business, shared connectivity is probably fine. If your business depends on every call being clear and every cloud session being responsive every day, DIA is worth the investment.

## The installation timeline

One practical consideration with DIA is that provisioning takes time. While a cable connection or shared fiber can typically be installed within a week or two, DIA often takes 30 to 90 days from order to activation. This timeline can be longer if construction is involved, meaning if fiber needs to be physically built to your location.

This means DIA isn't a quick fix for an immediate problem. If you're having connectivity issues today and you decide you need DIA, you'll need an interim solution while the circuit is being provisioned. Planning ahead, especially if you're moving to a new office or know that a lease renewal is coming up, gives you the time to get DIA in place before you need it rather than scrambling after the fact.

## A note on the term "business grade"

You'll hear a lot of providers use the phrase "business grade" to describe their products. It's worth knowing that this term doesn't have a standardized definition in the industry. A cable company can call their business cable plan "business grade." A fiber provider can call their shared fiber product "business grade." And a DIA provider uses the same language.

The distinction that matters isn't the marketing label. It's whether there's a committed information rate or a best-effort "up to" number, what the SLA's targets, measurement points, repair interval, and service credits actually are, and where the service demarcation sits. Those are the concrete differences that affect your actual experience. When you're evaluating proposals, look past the branding and ask about the specifics. We'll cover exactly what questions to ask in the [Reading an ISP Quote](/blog/reading-isp-quote) post later in this series.

---

*Next up: [Fixed Wireless: The Dark Horse](/blog/fixed-wireless), the connection type you might not have considered, and why it's worth a look in the right situation.*

---

### Part 7: Fixed Wireless: The Dark Horse

URL: https://voiptest.com/blog/fixed-wireless
Published: 2026-04-01
Tags: isp-selection, fixed-wireless, business-internet

*Getting the Internet Right: Part 7 of 12*

When most people think about business internet options, they think about the usual suspects: DSL, cable, fiber. Fixed wireless rarely enters the conversation, and that's a shame, because in the right situation it can be an excellent choice that solves problems the more familiar options can't.

Fixed wireless is exactly what it sounds like. It's an internet connection delivered wirelessly, using radio signals between an antenna on your building and a tower or tall building operated by the provider. Unlike mobile wireless (your cell phone), fixed wireless uses a stationary antenna pointed directly at the provider's equipment, which gives it characteristics much closer to a wired connection than most people expect.

## How fixed wireless works

The basic setup is straightforward. The provider installs a small antenna on the roof or exterior wall of your building. That antenna establishes a direct radio link with a base station that the provider operates, usually on a tower, a rooftop, or some other elevated structure within a few miles of your location. The base station connects to the provider's backbone network, typically via fiber, and from there you reach the broader internet.

The link between your antenna and the base station needs a clear or mostly clear path. This is called "line of sight," and it's the most important factor in whether fixed wireless will work at your specific location. If there's a tall building, a hill, or dense tree cover between your building and the provider's base station, the signal may not be able to reach you, or it may be degraded enough that the connection won't be reliable.

Some fixed wireless providers use frequencies that are more forgiving about obstructions than others. Lower frequency signals can partially penetrate or bend around obstacles, while higher frequency signals, particularly millimeter wave frequencies, need a cleaner path. The specific technology the provider uses determines how strict the line of sight requirement is.

## The performance profile

Fixed wireless performance varies significantly depending on the technology, the frequency, and the provider. At the lower end, you might see speeds comparable to a good [DSL](/blog/dsl-connection) connection. At the higher end, modern fixed wireless using millimeter wave or licensed spectrum can deliver symmetrical speeds of 100 Mbps to a gigabit with latency and jitter that rival fiber.

The variability in fixed wireless performance is one reason the technology has a mixed reputation. Early fixed wireless deployments, particularly those using unlicensed spectrum in the 2.4 GHz and 5 GHz bands, were susceptible to interference from other wireless devices in the area and could be unreliable. If you tried fixed wireless ten years ago and had a bad experience, the technology has improved considerably since then.

The key factors that determine fixed wireless quality are:

**Licensed versus unlicensed spectrum.** Providers using licensed spectrum have exclusive rights to their frequency range in their area, which dramatically reduces interference from other operators -- and, just as importantly, gives the provider legal recourse when interference does occur. It doesn't make interference physically impossible: adjacent-channel energy, faulty equipment, and unauthorized transmitters can still cause problems even in licensed bands. But it's a big deal nonetheless. Unlicensed spectrum is shared by design, and while modern equipment is much better at dealing with interference than older gear, licensed spectrum provides a fundamentally more reliable foundation.

**Frequency band.** Higher frequencies generally support higher speeds but require cleaner line of sight and are more affected by weather. Lower frequencies travel further and handle obstructions better but support lower speeds. Many providers use a mix, with higher frequencies for high capacity connections and lower frequencies for connections that need to work at longer distances or through moderate obstructions.

**Contention ratio.** Just like cable internet, some fixed wireless providers share the capacity at each tower among multiple customers. The split ratio and the number of active customers on a given tower determine how much contention there is. Better providers engineer their networks with enough capacity per tower to avoid congestion issues, but not all providers are equally disciplined about this.

**Weather sensitivity.** Radio signals at higher frequencies can be affected by heavy rain, a phenomenon called rain fade. The severity depends on the frequency and the distance. Shorter links and lower frequencies are less affected. For most well engineered fixed wireless connections, rain fade causes a temporary reduction in maximum throughput rather than an outage, and the effect is minimal on shorter links.

## Where fixed wireless shines

Fixed wireless fills some gaps that other technologies can't easily reach.

**Areas where fiber isn't available and cable is the only wired option.** If your building is in an area where the cable infrastructure is old or congested and fiber hasn't been built out yet, fixed wireless may offer a better connection than cable, especially from a provider using licensed spectrum. This is common in suburban business parks, industrial areas, and smaller cities where the wireline infrastructure hasn't kept pace with demand.

**Buildings where running new cable is difficult or expensive.** Some buildings, particularly older ones, historic buildings, or buildings with complicated tenant situations, make it impractical to bring in new wired service. Fixed wireless only needs an exterior antenna and a cable run from the roof to your suite, which avoids the need for construction in shared spaces or expensive conduit work.

**Fast deployment.** Fixed wireless can often be installed in days rather than weeks or months. If you need a connection quickly, whether for a new location, a temporary office, or because your primary connection just went down and the repair timeline is unacceptable, fixed wireless can bridge the gap much faster than a new wired circuit.

**Redundancy.** Because fixed wireless uses a different last-mile path than wired connections, it's an excellent choice for a backup circuit. If your primary connection is fiber or cable and the cable gets cut, whether by a construction crew, a car hitting a utility pole, or anything else that damages underground or aerial plant, the wireless link to your building is unaffected. One thing to verify before counting on it, though: diversity in the last mile doesn't guarantee diversity everywhere. The provider's base station backhauls to the internet over fiber of its own, needs power, and may even ride the same upstream network as your primary. Ask whether the tower's backhaul route, power, and upstream provider overlap with your primary circuit -- a backup that shares a failure point with the thing it's backing up is less redundant than it looks. We'll explore this more in the [Redundancy and Failover](/blog/redundancy-failover) post.

## Where fixed wireless struggles

**Dense urban areas with tall buildings.** Getting a clear line of sight to a provider's tower can be challenging when you're surrounded by taller buildings. Fixed wireless tends to work better at higher floors or in less dense settings.

**Heavily wooded areas.** Trees, particularly trees with dense foliage, can block or significantly degrade fixed wireless signals, especially at higher frequencies. This is an even bigger factor in deciduous forests, where the connection quality might change seasonally as leaves grow in and fall off.

**Very long distances.** While some fixed wireless technologies can work at distances of 10 miles or more, performance generally degrades with distance. The best fixed wireless experience is typically within a few miles of the base station.

**Extreme weather.** While normal rain and wind don't typically affect a well installed fixed wireless link, severe storms, heavy ice accumulation on the antenna, or extremely high winds can cause temporary service degradation or outage. This is rare, but it's worth knowing about if your business is in an area prone to severe weather.

## Evaluating a fixed wireless provider

If you're considering fixed wireless, there are a few specific things to ask the provider:

Are they using licensed or unlicensed spectrum? Licensed is strongly preferred for business use.

What frequency band? This tells you about the tradeoff between speed, distance, and weather sensitivity.

What is the contention ratio on the tower that would serve your location? Lower is better. Some providers offer dedicated bandwidth options on their fixed wireless network, similar to [DIA on fiber](/blog/dedicated-internet-access).

Will they do a site survey? A reputable provider will survey your location before committing, to verify that line of sight is achievable and that the signal quality will support the speeds they're quoting. Be wary of any provider that quotes speeds and signs you up without physically checking the path. After installation, running a [VoIP quality test](/tools/voip-test) will confirm whether the connection actually delivers the consistency that voice traffic demands.

What's the SLA? Some fixed wireless providers offer [SLAs](/blog/sla-contract-language) comparable to wired DIA providers. Others offer best effort service similar to cable. This varies significantly from provider to provider.

## The takeaway on fixed wireless

Fixed wireless has earned its place as a serious business internet option, not just a fallback for when nothing else is available. Modern fixed wireless using licensed spectrum and engineered properly can deliver performance that's competitive with wired connections at a competitive price point, often with faster installation.

The decision comes down to what's available at your specific location and how it compares to the wired options. In some areas, fixed wireless is genuinely the best available option. In others, it's a strong complement to a wired primary connection. And in others, the line of sight challenges make it impractical. A site survey from a qualified provider is the only way to know for sure.

---

*Next up: [Satellite: The Last Resort (and When It's the Only Resort)](/blog/satellite-internet), the option that's always available, and why that's both its greatest strength and its most common misconception.*

---

### Part 8: Satellite: The Last Resort (and When It's the Only Resort)

URL: https://voiptest.com/blog/satellite-internet
Published: 2026-04-02
Tags: isp-selection, satellite-internet, starlink, business-internet

*Getting the Internet Right: Part 8 of 12*

Satellite internet has one enormous advantage over every other connection type we've covered in this series: it works almost everywhere. If you can see the sky, you can get satellite internet. There's no cable to run, no fiber to build, no tower to have line of sight to. The provider's equipment is in orbit, and your dish points at it.

For businesses in truly remote locations, where none of the wired or fixed wireless options we've discussed are available, satellite may be the only option. And that's a legitimate use case that deserves an honest evaluation rather than a dismissal. But satellite also has fundamental limitations that make it a poor choice for anything involving real time communication, which means VoIP, unless you understand those limitations and plan around them.

## How satellite internet works

Traditional satellite internet uses geostationary satellites orbiting about 22,000 miles above the Earth's equator. A dish on your building sends and receives signals to and from the satellite, which relays them to a ground station connected to the internet backbone. This is the technology used by providers like HughesNet and Viasat, and it's been available for years.

The newer approach, most prominently represented by Starlink, uses low Earth orbit (LEO) satellites positioned at altitudes of roughly 300 to 350 miles. Thousands of these smaller satellites work together in a constellation, with your data hopping between satellites and ground stations to reach the internet. This is a fundamentally different architecture than traditional geostationary satellite, and the distinction matters a lot for business use.

## The latency problem with traditional satellite

The defining limitation of geostationary satellite internet is latency. Remember, these satellites are 22,000 miles up. Your data has to travel from your dish to the satellite (22,000 miles), from the satellite to a ground station (22,000 miles back down), and then the response has to make the same trip in reverse. That's roughly 88,000 miles round trip at the speed of light, which gives a theoretical speed-of-light minimum of about 480 milliseconds. In practice, with equipment processing and routing overhead, typical observed round-trip latency lands in the 500 to 650 millisecond range before any queueing delay is added on top.

To put that in perspective, be careful to compare like with like: voice guidance is expressed one-way, while the satellite figure above is round-trip. ITU-T G.114's transmission planning guidance cites [150 milliseconds of one-way (mouth-to-ear) delay](/blog/latency-jitter-packet-loss-details) as a commonly used planning boundary: not a point where audio suddenly fails, but the region beyond which conversational interactivity measurably degrades, with the actual effect depending on total mouth-to-ear delay and echo control. Geostationary satellite adds roughly 250 to 300 milliseconds one-way (half of that 500 to 650 millisecond round trip) before codec, jitter buffer, and terrestrial routing delays are stacked on, which puts the total far past the planning boundary. This makes phone calls over geostationary satellite frustrating. Both parties experience long, awkward pauses. People talk over each other constantly because neither person can tell when the other has stopped speaking. It's technically possible to hold a VoIP call over geostationary satellite. It's just not a conversation anyone would describe as having normal turn-taking.

This latency is a hard physical limitation. No amount of technology improvement can reduce it because it's determined by the speed of light and the distance to the satellite. The satellite is where it is because it needs to be at that altitude to maintain a geostationary orbit. There's no engineering around this.

## LEO satellite: the Starlink factor

Low Earth orbit satellite, particularly Starlink, has changed the conversation significantly. Because the satellites are orbiting at around 340 miles instead of 22,000 miles, the latency is dramatically lower. Typical measured round-trip latency on Starlink is in the range of 25 to 60 milliseconds, which is comparable to many wired connections and leaves plenty of room inside one-way voice planning budgets. LEO service still depends on coverage, obstructions, cell capacity, weather, ground station placement, and local regulatory availability, all of which we'll get to below; [VoIP over Starlink specifically](/blog/voip-over-starlink) has its own guide covering CGNAT and inbound calling.

Starlink also offers speeds that are respectable for business use, typically 50 to 250 Mbps download and 10 to 40 Mbps upload, though these numbers vary by location and time of day. The service has a business tier that offers higher priority and slightly better terms than the residential product.

On paper, these numbers sound quite good. And in practice, Starlink can work for VoIP, which is a statement that would have been absurd to make about satellite internet just a few years ago. But there are caveats that matter for business use.

## The caveats with LEO satellite

**Consistency.** LEO satellite speeds and latency vary more than wired connections. The satellites are constantly moving across the sky, your terminal is switching between different satellites as they pass overhead, and the routing of your traffic through the constellation can change from moment to moment. This creates variability in performance that is noticeable compared to a fixed wired connection. On average, the performance is good. At any specific moment, it might be great or it might be mediocre.

For web browsing and general internet use, this variability is invisible. For VoIP, it can manifest as occasional moments of degraded quality, brief dropouts or audio artifacts that come and go without any clear pattern. A [VoIP quality test](/tools/voip-test) run over several hours can show you the range of latency and jitter your satellite connection actually produces, which is more useful than a single speed test snapshot. Whether this is acceptable depends on your tolerance for imperfection and how critical call quality is to your business.

**Weather sensitivity.** Heavy rain, wet snow, and severe storms can degrade satellite signals. LEO satellite handles weather better than geostationary satellite due to the shorter signal path, but it's not immune. In areas with frequent severe weather, you may experience occasional service degradation during storms.

**Data caps and prioritization.** Some satellite plans have data caps or throttling thresholds, even on business plans. Once you exceed a certain amount of usage, your speeds may be reduced. Even plans marketed as "unlimited" may have priority tiers where heavy users get deprioritized during congestion. Read the terms carefully.

**Congestion.** As more customers sign up for LEO satellite service in a given area, the capacity per user can decrease. This is similar to the congestion issue with shared wired connections but harder to predict because it depends on subscriber density in your geographic cell, which can change over time as the service grows.

**Obstructions.** While LEO satellite is less sensitive to obstructions than geostationary (because it's connecting to satellites at various positions across the sky rather than one fixed point), it still needs a relatively clear view of the sky. Trees, tall buildings, and other obstructions can cause intermittent connectivity as satellites pass behind obstructed parts of the sky. The Starlink app includes a tool for checking obstructions at your installation location, and it's worth using before committing.

## Satellite for VoIP: the honest assessment

Traditional geostationary satellite is a poor fit for VoIP. Calls complete and audio flows, but the delay severely impairs natural turn-taking, and no configuration tuning changes the physics. If geostationary is your only option and you need phone service, you should look at a traditional phone line (POTS) if available, or a cellular based phone solution. Don't run VoIP over geostationary satellite and expect anyone to be happy with the conversational experience.

LEO satellite (Starlink) can support VoIP, and in many situations it works quite well. But it's not going to deliver the same consistency as a wired connection. If you're in a location where Starlink is your only internet option and you need to make phone calls, it's a viable choice. If you have wired options available and are considering Starlink as a primary connection specifically for voice, the wired options will give you better consistency.

Where Starlink works very well for VoIP is as a backup connection. Because it's completely independent of any ground based infrastructure, a satellite backup provides protection against the most common causes of wired outages: cut cables, utility pole damage, carrier equipment failure, and widespread local outages. We'll discuss this more in the [Redundancy and Failover](/blog/redundancy-failover) post.

## When satellite is the right choice

Satellite earns its place for businesses in locations where the alternatives are truly limited. Rural areas without cable or fiber, locations too remote for [fixed wireless](/blog/fixed-wireless), remote work sites, agricultural operations, and businesses in areas where the wired infrastructure is unreliable and unlikely to be upgraded.

For these situations, LEO satellite has been a genuine transformation. Businesses that previously had no viable internet option, or were stuck on barely functional DSL or a slow, high latency geostationary satellite connection, now have access to usable broadband. That's a big deal, and it's worth acknowledging even while being honest about the technology's limitations.

Satellite can also serve as a useful supplement in areas with only one wired provider. If the only other option is a single cable company with a spotty track record, adding Starlink as a secondary connection gives you diversity and a fallback that's independent of the local wired infrastructure.

## What satellite is not

Satellite is not a replacement for [fiber](/blog/fiber-internet), DIA, or a good wired connection in areas where those options exist. The marketing around LEO satellite has been aggressive, and it's created an impression in some people's minds that satellite is now competitive with fiber for all use cases. It isn't. For raw speed, consistency, latency, and reliability, a good wired connection beats satellite every time. Satellite has gotten dramatically better, but it's still the option you choose when you can't get something better, or as a backup to something better.

That's not a criticism. Knowing what each technology does well and where it falls short is exactly the point of this series. Every connection type has its place, and satellite's place is clear: it's the connection that's available everywhere, and for the locations where it's the best available option, modern LEO satellite is good enough to run a business on. It just isn't the first choice when you have other options.

---

*Next up: [SLAs: The Contract Language That Actually Matters](/blog/sla-contract-language), understanding the promises your provider is making, and the ones they're not.*

---

### Part 9: SLAs: The Contract Language That Actually Matters

URL: https://voiptest.com/blog/sla-contract-language
Published: 2026-04-03
Tags: isp-selection, sla, business-internet, contracts

*Getting the Internet Right: Part 9 of 12*

If you've been reading this series, you've seen the term SLA come up multiple times. It showed up when we talked about [dedicated internet access](/blog/dedicated-internet-access), when we compared [shared versus dedicated fiber](/blog/fiber-internet), and in passing when discussing almost every connection type. That's because the SLA, which stands for Service Level Agreement, is often the single most important difference between a connection that's being sold as a business product and one that just happens to be available to businesses.

An SLA is, at its most basic, a set of promises that the provider puts in writing about the performance and availability of their service. It's also a set of remedies that define what happens when those promises aren't kept. Understanding what's in an SLA, what's typically not in one, and how to tell a strong SLA from a weak one gives you a much clearer picture of what you're actually buying when you sign a contract with an internet provider.

## What an SLA typically covers

A standard ISP SLA for a business connection addresses several categories of performance. Not every SLA covers all of these, and the specific guarantees vary significantly from provider to provider. Here are the main ones to look for.

**Uptime guarantee.** This is the big one. The uptime guarantee expresses, as a percentage, how much of the time the provider commits to having your connection available and operational. You'll commonly see figures like 99.9%, 99.95%, or 99.99%.

These numbers look very similar at first glance, but the differences are significant when you translate them into actual downtime. A 99.9% uptime guarantee allows for about 8 hours and 45 minutes of downtime per year. A 99.99% guarantee allows for about 52 minutes. That's the difference between a full business day of outage being within acceptable bounds and less than an hour per year being the maximum.

When evaluating an uptime guarantee, pay attention to how the provider defines "downtime." Some providers define downtime as a complete loss of connectivity to your premises. Under that definition, a circuit that's up but performing so poorly that your phones are unusable and your cloud apps are timing out might not count as downtime. A better SLA defines downtime as failure to meet any of the performance guarantees, not just total loss of connectivity.

Also check whether the uptime guarantee excludes scheduled maintenance. Many SLAs do, meaning the provider can take the circuit down for maintenance and that time doesn't count against their uptime commitment. This is fairly standard, but you should know what the maintenance windows look like and how much advance notice you'll get.

**Latency guarantee.** This specifies the maximum round trip latency between your connection and the provider's backbone, or between their backbone and certain measurement points on the internet. A typical latency guarantee for DIA might be something like "less than 40 milliseconds round trip within our network." This is important for VoIP because, as we covered early in the series, excessive latency creates conversational delays that make phone calls feel unnatural.

**Packet loss guarantee.** This specifies the maximum acceptable rate of lost packets on the provider's network. A strong SLA will guarantee less than 0.1% packet loss. Some guarantee less than 0.01%. For voice traffic, even small amounts of [packet loss](/blog/understanding-voip-packet-loss) cause audible quality degradation, so this number matters.

**Jitter guarantee.** Some SLAs include a maximum jitter figure, though this is less common than latency and packet loss guarantees. If it's included, you'll typically see a guarantee of less than 1 to 5 milliseconds. Given how sensitive voice is to [jitter](/blog/what-is-jitter-and-why-it-matters), having this in the SLA is valuable if you can get it.

**Mean Time to Repair (MTTR).** This specifies how quickly the provider commits to restoring service after an outage. A typical MTTR guarantee for DIA might be 4 hours. Some premium services offer 2 hours or even 1 hour. This doesn't mean every outage will be fixed within that window, but it sets an expectation and a baseline for credits if the provider exceeds it.

## What happens when the SLA is violated

The enforcement mechanism in most SLAs is the service credit. If the provider fails to meet a guaranteed metric, they owe you a credit against your monthly bill. The credit amount is usually calculated as a percentage of your monthly recurring charge for each increment of time that the guarantee was missed.

For example, an SLA might specify that for each hour of downtime beyond the guaranteed uptime, you receive a credit equal to 5% of your monthly bill, up to a cap of 30% or 50% of one month's charges.

Let's be realistic about what this means. Service credits are not a windfall. They're not going to cover the business impact of a major outage. If your phones are down for six hours and you lose $10,000 in sales opportunities, a $200 credit on your $600 monthly bill doesn't make you whole.

What service credits do accomplish is creating an incentive structure. The provider has a financial motivation to meet their guarantees because SLA credits come directly out of their revenue. Providers also track SLA performance internally, and poor performance affects their operational metrics. The SLA creates accountability even when the dollar amounts of individual credits are small.

## Claiming SLA credits

Here's something most businesses don't realize: in many cases, you have to proactively claim SLA credits. The provider won't automatically credit your account when they miss a guarantee. You need to notice the issue, document it, submit a claim within a specified time frame (often 30 days), and the provider then evaluates the claim against their records.

This means you need to be monitoring your connection's performance, at least at a basic level, to know when the SLA is being violated. You also need to read the SLA's claims process so you know the deadline and requirements. Many valid SLA claims go unclaimed simply because the customer didn't know about the process or didn't submit the paperwork in time.

Some providers have started making this process more transparent, with dashboards that show performance metrics and automated credit processing. If you're evaluating two similar DIA proposals, the provider with a more transparent SLA credit process is, all else being equal, the better choice.

## Shared connections and SLAs

One of the most significant differences between shared and dedicated connections is the SLA, or the lack of one.

Most [cable internet](/blog/cable-internet) plans, even business ones, either don't include a meaningful SLA or include one that's so weak it barely qualifies. A typical cable business SLA might guarantee uptime with generous exclusions but include no guarantees whatsoever about latency, jitter, or packet loss. The connection could be up but performing terribly, and the SLA hasn't been violated.

Shared fiber products are similar. Some include modest SLAs, but they generally don't guarantee the performance metrics that matter most for voice quality. You might get a vague commitment to "best effort" performance, which means the provider will try but doesn't promise anything specific.

DIA connections come with the strongest SLAs. Guaranteed uptime with narrow exclusions, guaranteed latency, guaranteed packet loss, often guaranteed jitter, and defined remedies for violations. This is a major part of what you're paying for with the premium pricing of DIA.

If your VoIP provider ever tells you that your call quality problems are on the ISP side, having an SLA with performance guarantees gives you something concrete to hold the ISP accountable with. Without an SLA, you're left explaining symptoms and hoping the provider investigates. With an SLA, you can point to specific guaranteed metrics and say, "You committed to less than 0.1% packet loss, and my monitoring shows 2% over the last week."

## Reading between the lines

A few things to watch for when evaluating SLAs:

**Credit caps.** Most SLAs cap the total credits you can receive in a billing period, typically at 30 to 100% of one month's charges. This means that even in a catastrophic outage lasting days, your maximum credit is one month free. Know what the cap is and consider whether it's reasonable given the impact an extended outage would have on your business.

**Exclusions.** Read the exclusion list carefully. SLAs commonly exclude downtime caused by scheduled maintenance, force majeure events, issues with your equipment, issues with services or networks outside the provider's control, and outages you cause or contribute to. These exclusions are mostly reasonable, but some providers have creative exclusion language that narrows their obligations more than you'd expect.

**Measurement methodology.** How does the provider measure the guaranteed metrics? Do they measure at your premises, at their edge, or at some other point? A latency guarantee that only covers the provider's backbone network and excludes the last mile isn't covering the segment that's most likely to have issues.

**Term versus month to month.** Some SLAs are only available on term contracts (12, 24, or 36 months). The SLA on a month to month arrangement, if there is one, may be weaker. Understand what you're getting and what commitment you're making in return.

## The bottom line on SLAs

An SLA is not a guarantee that nothing will ever go wrong. Things go wrong with every provider, every connection type, and every technology. What an SLA gives you is a clear set of expectations, a defined measurement framework, and a mechanism for accountability when those expectations aren't met.

For businesses that depend on their internet connection for revenue generation, customer communication, and daily operations, the presence and strength of the SLA should be a significant factor in the buying decision. Not the only factor, but one that deserves real attention rather than being treated as fine print to skip past.

---

*Next up: [Redundancy and Failover: When One Connection Isn't Enough](/blog/redundancy-failover), building a backup plan for the thing that everything depends on.*

---

### Part 10: Redundancy and Failover: When One Connection Isn't Enough

URL: https://voiptest.com/blog/redundancy-failover
Published: 2026-04-04
Tags: isp-selection, redundancy, failover, business-internet

*Getting the Internet Right: Part 10 of 12*

Everything we've covered in this series so far has been about choosing the right primary internet connection. But here's an uncomfortable truth: every type of internet connection, even the best ones, goes down sometimes. Cables get cut. Equipment fails. Providers have outages. Storms take out infrastructure. A backhoe operator digging up a parking lot doesn't check for buried fiber before starting. When it happens, your phones react in a specific, predictable sequence; we walk through it minute by minute in [what happens to your phones when the internet goes down](/blog/what-happens-to-phones-when-internet-goes-down).

If your business can afford to be offline for a few hours, or even a day, without serious consequences, then a single well chosen connection is probably fine. But if being offline means you can't take calls from customers, can't process transactions, can't access your cloud applications, or can't communicate with your team, then relying on a single connection is a gamble. It's not a question of whether it will go down. It's a question of when, for how long, and what it costs you.

Redundancy means having more than one connection so that when one fails, the other can take over. Failover is the mechanism that makes the switch happen. Together, they're your insurance policy against the thing that everything else in your business depends on.

## The basic concept

The simplest form of redundancy is two internet connections from two different providers, ideally using two different technologies and two different physical paths. If your primary connection is cable from Provider A, your backup might be [fixed wireless](/blog/fixed-wireless) from Provider B, or DSL from Provider C, or a cellular connection. The goal is diversity. If one goes down, the other shouldn't go down at the same time for the same reason.

This sounds simple, and conceptually it is. But the details matter a lot, because poorly planned redundancy gives you a false sense of security that's arguably worse than knowing you have no backup at all.

## Why provider diversity matters

Having two connections from the same provider might not protect you as much as you think. If both connections use the same provider's network, a single failure in that provider's infrastructure could take out both circuits simultaneously. This happens more often than people expect. A router failure at the provider's local facility, a fiber cut on their backbone, or a software issue that affects their entire network will take down every connection you have with them.

Using two different providers gives you protection against provider level failures. But even this isn't enough by itself.

## Why physical path diversity matters

Consider this scenario: you have cable from one provider and fiber from a different provider. Great, two different providers, two different technologies. But both cables enter your building through the same conduit, cross the same utility right of way, and run along the same stretch of road. A single construction accident, a vehicle hitting the right utility pole, or flooding in the right spot can take out both connections at once because they share the same physical path for some portion of their route.

True physical path diversity means the two connections take completely different routes to reach your building. This is easier said than done, and it's one of the reasons wireless backup connections (fixed wireless or [satellite](/blog/satellite-internet)) are popular for redundancy. A wireless connection doesn't use any of the same last-mile infrastructure as a wired connection, so a cable cut can't affect both. One caution if voice is the workload you're protecting: a geostationary satellite hop adds several hundred milliseconds of one-way delay, far beyond the roughly 150 ms one-way figure ITU-T G.114 uses as a transmission-planning boundary, so calls on that backup will work but will feel noticeably different.

The shared-path problem also extends beyond the cable in the ground. Two access links are only genuinely diverse if they're independent at every layer you can verify: different underlying carriers (a reseller may ride the same wholesale network as your "other" provider), different building entrances and conduits, different utility poles and rights of way, different backhaul routes, different provider points of presence, and different power dependencies (a backup circuit whose street cabinet loses power in the same outage as your primary isn't a backup). Control-plane dependencies count too: if both connections resolve names through the same DNS infrastructure, or your VoIP service locates its servers through DNS (as SIP does per RFC 3263) and that resolution path is shared, a DNS failure defeats the redundancy even though both physical links stay up.

If both your connections are wired, it's worth asking each provider how their cable reaches your building and whether the two paths share any of the infrastructure above. In practice, achieving complete physical diversity with two wired connections is sometimes impossible, especially in areas where all the utility infrastructure runs along the same corridor. But even partial diversity is better than no diversity, as long as you know exactly which failure modes it does and doesn't cover.

## How failover works

Having two connections doesn't help if the switch between them isn't handled correctly when the primary fails. Failover can be automatic or manual, and the difference matters.

**Automatic failover** uses a router or firewall that monitors both connections and switches traffic to the backup when the primary goes down. Good routers do this within seconds, so the disruption is brief. The best setups monitor not just whether the connection is up but whether it's performing adequately, so the failover triggers on degradation, not just total failure. This is important because some outages aren't clean. The connection might stay technically up but with such high packet loss or latency that it's functionally useless. A failover system that only triggers on complete loss of connectivity won't help in these situations.

**Manual failover** means someone has to notice the outage and take action, whether that's switching a cable, logging into a router, or calling someone to make a change. This is cheaper to set up but introduces a delay between the outage and the recovery. If the outage happens at 3 PM on a Tuesday when the IT person is in the office, the delay might be a few minutes. If it happens at 8 PM on a Saturday, it might be hours before anyone notices and responds.

For businesses where connectivity is critical during business hours, automatic failover is worth the investment. The hardware to support it is not exotic or excessively expensive. Most modern business routers and firewalls support dual WAN connections with automatic failover, and configuring it is straightforward for anyone with basic networking knowledge.

## What happens to your phone calls during a failover

If your phones are VoIP and your internet goes down, your calls drop. If the failover happens quickly, say within five to ten seconds, active calls will likely drop but new calls can be placed almost immediately on the backup connection. If the failover takes minutes, you're offline for that entire period.

Some VoIP systems handle failover better than others. [Cloud hosted phone systems](/blog/what-is-voip), where the PBX is in the provider's data center rather than in your office, tend to handle connection changes more gracefully because the call routing intelligence isn't tied to your specific internet connection. If your internet fails over to a backup, the cloud PBX doesn't care which connection you're using. It just sees your phones reconnect.

On premises phone systems can be more sensitive to connection changes, depending on how they're configured. If your PBX registers with the VoIP provider using the IP address of your primary connection, and the failover switches you to a different IP address, the registration may need to re-establish before calls can flow. This can add delay to the recovery.

It's worth testing your failover scenario with your actual phone system before you need to rely on it. Disconnect the primary connection deliberately during a low traffic period and observe what happens. How long until the phones reconnect? Do active calls survive the switch? Does everything come back up automatically, or does something need to be manually restarted? Finding out the answers during a planned test is much better than finding out during a real outage.

## Common redundancy configurations

**Cable primary, cellular backup.** This is one of the most common and affordable setups for small businesses. Your primary connection is cable or fiber, and you keep a cellular failover device (often called an LTE or 5G failover router) that activates when the primary goes down. Cellular has the advantage of being completely independent of your wired infrastructure. The downside is that cellular bandwidth is limited and can be expensive if you're on a metered plan, and cellular can be congested in dense areas.

**Fiber primary, fixed wireless backup.** A good combination for businesses that need more bandwidth on the backup than cellular can provide. The fixed wireless connection takes a completely different physical path since it's wireless, providing true path diversity. If the provider uses licensed spectrum, the backup can be quite reliable.

**DIA primary, cable backup.** For businesses that have DIA as their main connection, a cable line as backup provides a cost effective fallback. The cable connection doesn't need to deliver the same quality as the DIA. It just needs to keep things running until the primary is restored.

**DIA primary, DIA secondary.** For businesses where even brief outages are unacceptable, two DIA connections from different providers on different physical paths provides the highest level of redundancy. This is the most expensive option but provides the best protection and allows for load balancing across both connections during normal operation.

## The cost question

Redundancy costs money, both for the second connection and for the equipment to manage the failover. For some businesses, the cost is hard to justify when the primary connection is working fine, because you're paying for something you hope you'll never use.

The way to evaluate this is to estimate the cost of an outage. If your business generates $5,000 per day in revenue and an internet outage means you can't take orders, process transactions, or communicate with customers, then a full day outage costs you $5,000 or more. If a backup connection costs $100 a month and saves you from even one full day outage per year, the math is straightforward.

For businesses where the financial impact of downtime is hard to quantify, think about the operational and reputational costs. Employees sitting idle because they can't access their tools. Customers calling and getting no answer. A partner trying to reach you and hearing dead air. These costs are real even if they don't show up on a spreadsheet.

## Setting it up right

If you decide to implement redundancy, a few practical considerations:

Make sure both connections are tested regularly. A backup that's been sitting idle for six months might have developed a problem you don't know about until you need it.

Configure your failover to test connectivity to something beyond your provider's network, not just to the provider's gateway. A connection that reaches the provider's first router but can't get to the broader internet isn't useful.

Consider whether certain traffic should always use one connection over the other. Some setups route voice traffic over the more reliable connection and general internet traffic over the less expensive one, using both connections actively rather than keeping one as a cold standby.

Document your setup so that when an outage happens, whoever is responding knows what to expect and what to check.

---

*Next up: [Reading an ISP Quote: The Questions You Should Be Asking](/blog/reading-isp-quote), how to evaluate what you're being offered and compare proposals that don't make it easy to compare.*

---

### Part 11: Reading an ISP Quote: The Questions You Should Be Asking

URL: https://voiptest.com/blog/reading-isp-quote
Published: 2026-04-05
Tags: isp-selection, isp-quotes, business-internet, contracts

*Getting the Internet Right: Part 11 of 12*

You've decided you need better internet for your business. Maybe you've been reading this series and realized your current connection isn't the right fit. Maybe you're moving to a new office. Maybe your calls have been sounding terrible and you've ruled out everything else. Whatever the reason, you've reached the point where you're looking at proposals from internet providers and trying to figure out which one to go with.

This is the part where a lot of businesses get into trouble. ISP quotes are not standardized. Every provider uses different terminology, structures their pricing differently, and emphasizes different things. Comparing two quotes side by side and understanding which one is actually the better deal requires knowing what to look for and, just as importantly, what to ask about when the information isn't there.

## The monthly recurring charge is not the whole price

The most prominent number on any ISP quote is the monthly recurring charge, or MRC. This is the monthly price you'll pay for the service. It's the number providers lead with because it's usually the most competitive looking figure they can offer.

But the MRC is often not the total cost. There are several other charges that may apply and that you need to ask about if they're not clearly stated.

**Installation fees.** These can range from zero to thousands of dollars depending on the connection type and whether construction is required. Some providers waive installation fees in exchange for a longer contract term. Others bury them in the fine print. Ask specifically what the installation cost is, whether it's a one time charge or amortized over the contract, and what happens with construction charges if fiber needs to be built to your location.

**Equipment fees.** The modem, router, or other customer premises equipment (CPE) required for the connection may be included in the MRC, rented separately, or something you're expected to purchase yourself. Some providers charge a monthly equipment rental fee that adds $10 to $50 per month on top of the quoted MRC. Others include it but require you to return it at the end of the contract or pay a fee. Ask what equipment is included, whether there's a separate charge for it, and who owns it.

**Taxes, fees, and surcharges.** Just like your cell phone bill, business internet bills often include regulatory fees, universal service fund charges, and various surcharges that aren't included in the quoted MRC. These can add 10 to 20% to your monthly cost. Ask for an estimate of what your total bill will be, not just the service rate.

**Early termination fees.** If you sign a 24 or 36 month contract and need to cancel early, whether because you're moving, the service is inadequate, or your business needs change, most providers charge an early termination fee (ETF). This is often calculated as the remaining MRC for the unused portion of the contract, which can add up to thousands of dollars. Understand the ETF before you sign.

## Understanding what "speed" means on the quote

When a quote says "100 Mbps," you need to know several additional things before that number means anything useful.

Is it symmetrical or asymmetrical? A quote that says "100 Mbps" without specifying could mean 100 down and 100 up (symmetrical, typical for DIA) or 100 down and 10 up (asymmetrical, typical for [cable](/blog/cable-internet) and some shared fiber). This is a massive difference for business use, as we covered in [How Internet Connections Actually Work](/blog/how-internet-connections-work). Our [Bandwidth Calculator](/tools/bandwidth-calculator) can help you determine how much upload and download bandwidth your office actually needs, so you know what to insist on. Ask explicitly.

Is it dedicated or shared? As we discussed in the [fiber post](/blog/fiber-internet) and the [DIA post](/blog/dedicated-internet-access), 100 Mbps dedicated and 100 Mbps shared are fundamentally different products. The quote should make this clear, but if it doesn't, ask whether the bandwidth is guaranteed or best effort.

Is there a committed information rate? On DIA connections, the CIR should equal the quoted speed. On some shared or burstable connections, the CIR may be lower than the quoted speed, meaning you're guaranteed a minimum amount of bandwidth but can burst higher when capacity is available. Understand the difference between the guaranteed floor and the advertised ceiling.

Is there a data cap or usage threshold? Some connections, particularly cable and satellite, have data caps that limit your total usage per month. Others have soft caps where your speed is throttled or your traffic is deprioritized after a certain threshold. Ask whether there are any usage limits or throttling policies.

## The SLA section (or the absence of one)

If the quote includes DIA or any connection marketed as business grade, there should be an SLA section. Refer to the [SLAs post](/blog/sla-contract-language) in this series for what to look for.

If the quote doesn't include an SLA, or includes one that's vague and noncommittal, that tells you something important about the product. It doesn't necessarily mean the product is bad, but it means there are no guarantees about performance, and if you have problems, you'll be relying on the provider's good will rather than a contractual obligation.

## Contract term and auto renewal

Most business internet contracts are for 12, 24, or 36 months. Longer terms often come with lower monthly pricing or waived installation fees. Shorter terms or month to month arrangements cost more but give you flexibility.

Watch for auto renewal clauses. Many contracts automatically renew for another full term at the end of the initial period unless you provide written notice within a specific window, typically 30 to 90 days before the expiration date. If you miss that window, you could be locked in for another two or three years. Put a calendar reminder well before your renewal date so you have time to evaluate your options.

Also ask about rate increases at renewal. Some providers lock your rate for the initial term but increase it at renewal. Others maintain the rate. If the contract is vague about renewal pricing, assume it will go up and factor that into your planning.

## Comparing quotes that don't want to be compared

Providers don't make it easy to compare their proposals against each other, and there's a reason for that. Each one structures their offering to emphasize their strengths and obscure their weaknesses. One provider might quote a low MRC but have high installation fees. Another might have a higher MRC but include equipment and installation. A third might look expensive until you realize it includes a backup cellular connection that the others are charging extra for.

To compare quotes meaningfully, create your own comparison framework. For each quote, calculate the total cost of ownership over the contract term: MRC times the number of months, plus installation, plus equipment costs, plus estimated taxes and fees. Then compare the total cost alongside the service characteristics: bandwidth (upload and download separately), shared versus dedicated, SLA guarantees, contract term, and early termination terms.

This is admittedly tedious work, and it's one of the reasons many businesses don't do it. They look at the monthly price, pick the one that seems reasonable, and move on. We get it. But for a decision that will affect your daily operations for the next two or three years, spending an afternoon doing this comparison is time well spent.

## Questions to ask that aren't on the quote

Beyond what's printed on the proposal, there are a few questions worth asking the sales rep that can reveal a lot about what your experience will actually be like.

**What does your typical installation timeline look like?** The answer tells you whether they're running a simple cable or provisioning a new circuit. If it's DIA and they say "two weeks," dig deeper, because that timeline is unusually fast for a dedicated circuit and might indicate a shared product being sold as dedicated.

**What is your outage notification process?** When something goes wrong, how will you find out? Some providers have status pages, automated alerts, and proactive communication. Others leave you to discover outages on your own and call in to ask what's happening. The answer to this question tells you a lot about the provider's operational maturity.

**How loaded is the infrastructure that would serve my location?** For shared connections, this question gets at how congested the node, tower, or splitter is. Providers may not give you an exact number, but their willingness to discuss it, and the specificity of their answer, tells you something.

**Can I speak to a current customer in my area?** A confident provider will be willing to connect you with a reference. A provider that dodges this request may have good reasons, or may not.

**What's your average support response time?** Not the SLA guaranteed time, but the actual average. Some providers far exceed their SLA guarantees on a typical day. Others hit the SLA target and not a minute sooner.

## The decision is more than price

It's tempting to choose the cheapest option. Especially when internet feels like a commodity and one connection seems like any other. But by this point in the series, you know that's not true. The connection type, the provider's infrastructure, the SLA, the support quality, and the contract terms all matter.

The cheapest connection that meets your needs is a great choice. The cheapest connection that doesn't meet your needs is going to cost you more in the long run through lost productivity, [bad call quality](/blog/diagnosing-voip-problems), frustrated employees, and the time spent dealing with problems that a better connection wouldn't have had.

Compare thoughtfully, ask the right questions, and make the decision based on what your business actually needs.

---

*Next up: [How to Actually Choose: Putting It All Together](/blog/how-to-choose-isp), the final post in this series, where we combine everything into a practical decision framework.*

---

### Part 12: How to Actually Choose: Putting It All Together

URL: https://voiptest.com/blog/how-to-choose-isp
Published: 2026-04-06
Tags: isp-selection, business-internet, voip-troubleshooting

*Getting the Internet Right: Part 12 of 12*

You've made it through eleven posts about internet connection types, contract language, redundancy planning, and how to read a quote without getting lost. That's a lot of information, and if your head is swimming a little, that's understandable. The point of this final post is to take everything we've covered and turn it into a practical decision framework. Not a checklist that pretends every business is the same, but a way of thinking through the decision that accounts for your specific situation.

Because the right internet connection for a five person insurance agency is not the same as the right connection for a 40 person call center, and both of those are different from the right connection for a warehouse with a handful of office staff and a lot of IoT devices. The technology is the same. The decision isn't.

## Start with what you actually need, not what sounds impressive

The single most common mistake businesses make when choosing internet is buying based on the speed number without thinking about what they actually need the connection to do. A gigabit connection sounds great on paper, but if your office has twelve people making phone calls and using cloud applications, you don't need a gigabit. You need 50 to 100 Mbps that's rock solid.

Start by inventorying your actual usage. How many people are in the office? How many of them are on phones at any given time? Are those voice calls only, or are people doing video conferences? What cloud applications does your team rely on? Do you have any bandwidth intensive operations like large file transfers, cloud backups, or security camera footage uploading? Our [Bandwidth Calculator](/tools/bandwidth-calculator) can turn those answers into a concrete bandwidth number you can use when evaluating quotes.

For most small to medium businesses, the honest answer to "how much bandwidth do we need" is much less than they think. The more important question is what kind of bandwidth they need. If your inventory reveals that phone calls are a significant part of your daily operations, consistency matters more than raw speed. If your inventory reveals that you're mostly browsing the web and sending emails with occasional calls, you have more flexibility in your connection choice.

## Map your needs to connection types

Once you know what you need, you can narrow down the connection types that make sense. Here's a rough guide based on what we covered throughout the series.

If you're a small office with under ten people, moderate phone usage, and no mission critical real time applications, a shared fiber or cable connection will likely serve you well. Shared fiber is preferred if it's available at your address because of the better upload speeds and generally better consistency. Cable is a reasonable alternative where fiber isn't available.

If you're a medium office with ten to thirty people, regular phone usage, and meaningful reliance on cloud applications, shared fiber is the minimum you should be looking at. If your phone usage is heavy or if call quality is directly tied to revenue, [dedicated internet access](/blog/dedicated-internet-access) is worth the premium. The consistency guarantees and SLA protections become increasingly valuable as your dependency on the connection grows.

If you're a larger office or a business where phones are the primary tool, think call centers, sales floors, medical practices with high call volume, dedicated internet access should be your primary connection. The cost is higher, but the operational impact of inconsistent connectivity at this scale justifies it many times over.

If you're in a location where wired options are limited, [fixed wireless](/blog/fixed-wireless) using licensed spectrum is a strong contender. It can deliver performance competitive with wired connections in the right conditions, and a site survey from the provider will tell you whether your location qualifies. LEO [satellite (Starlink)](/blog/satellite-internet) is a viable option for locations where nothing else reaches, though it shouldn't be your first choice if wired or fixed wireless alternatives exist.

If your business can't afford to be offline for extended periods, add a redundant connection using a different technology and provider than your primary. The [Redundancy and Failover](/blog/redundancy-failover) post covers this in detail.

## Check what's actually available at your address

This is where theory meets reality. You might determine that dedicated fiber is the right choice for your business, only to discover that no provider offers it at your address without a $15,000 construction charge. Or you might assume cable is your only option and discover that a fiber provider built out your street last year and nobody told you.

Availability varies dramatically from address to address, sometimes from building to building on the same block. The only way to know what's available is to check.

You can start by searching provider websites with your address. Most major ISPs have an address checker on their site. But this approach has limitations. It only shows you the providers you think to look for. It doesn't show you the regional carriers, the smaller fiber providers, the fixed wireless operators, or the competitive carriers that serve business customers but don't advertise to consumers.

This is, frankly, one of the hardest parts of the process for most businesses. The carrier landscape in any given market is fragmented. There might be fifteen providers that could theoretically serve your address, but you'd never find most of them through a Google search. They sell through channel partners, they don't have consumer facing websites, or they're known in the telecom industry but invisible to end users.

## Get multiple quotes and compare them properly

Whatever approach you take to finding providers, get at least two or three quotes before you decide. As we covered in [Reading an ISP Quote](/blog/reading-isp-quote), compare the total cost of ownership over the contract term, not just the monthly rate. And compare the service characteristics: upload versus download speeds, shared versus dedicated, [SLA](/blog/sla-contract-language) terms, installation timeline, and contract flexibility.

If the quotes are wildly different in price for what seems like the same product, that's a signal to ask more questions. One provider might be quoting shared fiber while another is quoting dedicated. One might include installation while another doesn't. The numbers don't mean anything until you normalize them against a common set of specifications.

Don't be afraid to negotiate. Business internet pricing, especially for DIA, often has room to move. Providers are particularly willing to negotiate on installation costs, contract term, and sometimes the monthly rate if you're signing a longer commitment. If you've gotten a competitive quote from another provider, mentioning that (politely and honestly) can help.

## Consider the provider, not just the product

The connection type and the pricing are important, but so is the provider behind them. Two different companies can offer the same 100 Mbps DIA product and deliver very different experiences based on their network quality, support responsiveness, and operational competence.

Ask about their support model. Is there a dedicated account manager, or are you calling a general support line? What are their actual (not just SLA guaranteed) response times? Do they have a network operations center monitoring your circuit proactively, or are they reactive?

Ask about their network. Where are their facilities? How do they peer with other networks? A provider with strong peering relationships will deliver better performance to a wider range of destinations than a provider that routes everything through a single upstream transit provider. This matters for VoIP because your voice traffic needs to reach your VoIP provider's network efficiently.

If possible, talk to other businesses in your area that use the provider. Real world experience from someone in a similar situation is more valuable than anything on the provider's website.

## Make the decision and revisit it

At some point, you've done enough research and you need to pick one. No amount of analysis will give you perfect certainty, and delaying the decision while you chase one more quote or one more data point has a cost too.

Pick the option that best matches your needs at a price you can justify, with a provider that seems competent and responsive, and terms that don't lock you in for longer than you're comfortable with. Then pay attention to how the connection performs after installation. Run a [VoIP quality test](/tools/voip-test) shortly after installation to establish a baseline, and run it again periodically. Monitor your call quality. Keep track of any outages or issues. If the connection isn't meeting expectations, you'll have the knowledge from this series to diagnose why and the language to have a productive conversation with the provider about it.

And when your contract comes up for renewal, don't just let it auto renew. Revisit the decision. The carrier landscape changes. New providers enter markets. Existing providers build out infrastructure. The connection that was the best available option two years ago might not be the best option today. A fresh look at renewal time, with a clear understanding of how your current connection has actually performed, puts you in a strong position to either renegotiate or switch.

## The bigger picture

If you've read this entire series, you now understand more about business internet than the vast majority of business owners and office managers. That knowledge is genuinely useful. It means you can have informed conversations with providers instead of taking their word for everything. It means you can troubleshoot call quality problems more effectively because you understand the connection layer that your VoIP system sits on top of. And it means that when you make a decision about your internet, it's a real decision based on understanding rather than a guess based on a speed number and a price.

Your internet connection is the foundation that your phones, your cloud applications, and increasingly your entire operation sits on. Getting it right deserves as much attention as the phones themselves. For most businesses, by the time they find [voiptest.com](https://voiptest.com), they've been dealing with call quality problems long enough that the ISP variable has never been properly evaluated. That's the problem this series was written to address.

---

*This post brings together topics covered across the full series. If you're starting fresh, [Your ISP Is the Foundation Everything Else Sits On](/blog/isp-foundation) is the right starting point. For how VoIP quality problems get diagnosed beyond the connection layer, the [VoIP From the Ground Up series](/blog/how-does-a-phone-call-actually-work) covers the full picture.*

---

## Series: SIP Signaling From the Wire Up

A 12-part series that takes you from understanding what SIP is to reading packet captures and diagnosing real call problems. Covers message anatomy, call flows, registration, NAT traversal, security, trunking, and troubleshooting.

### Part 1: What SIP Actually Is (and What It Isn't)

URL: https://voiptest.com/blog/what-sip-actually-is
Published: 2026-04-07
Tags: sip, voip, signaling, protocol-fundamentals

*SIP Signaling From the Wire Up: Part 1 of 12*

If you work with [VoIP](/blog/what-is-voip) systems in any capacity, you've heard the term SIP. It shows up in configuration screens, in error messages, in conversations with providers, and in the names of products. SIP trunks. SIP phones. SIP credentials. The term is everywhere, but what SIP actually does, and more importantly what it doesn't do, is something a surprising number of people who work with voice systems every day couldn't explain clearly.

That's not a criticism. SIP is one of those technologies that works well enough most of the time that you can configure phones and trunks without ever understanding what's happening underneath. But when something goes wrong, and it will, understanding SIP is the difference between staring at a problem helplessly and knowing exactly where to look.

This series is going to take you from "I know SIP has something to do with phone calls" to "I can read a packet capture and figure out why this call isn't working." We'll go step by step, starting here with the basics, and by the end of the series you'll be reading raw SIP messages and diagnosing real problems.

## SIP is only the signaling

Here's the most important thing to understand about SIP, and the thing that clears up the most confusion: SIP does not carry voice. Not even a little bit. SIP's job is signaling. It handles the setup, modification, and teardown of communication sessions. Think of it like the host at a restaurant. The host greets you, finds you a table, and seats you. The host does not cook your food. That's someone else's job.

In VoIP, the "cooking" is done by RTP, which stands for Real-time Transport Protocol. RTP is the protocol that actually carries the voice audio between the two parties on a call. RTP runs on completely different ports than SIP, uses a completely different message format, and operates independently once the call is established.

This distinction is not just academic. It's the key to understanding a huge category of VoIP problems. When someone says "the call connected but there's no audio," what they're describing is a situation where SIP did its job perfectly (the session was established, both phones agreed to the call) but RTP failed (the audio packets aren't flowing). These are two separate systems, and they can succeed or fail independently.

A call connects but nobody can hear anything? That's an RTP problem, probably a [NAT or firewall issue](/blog/one-way-audio) preventing the audio packets from reaching their destination. The SIP side worked fine.

A call never rings at all? That's a SIP problem. The signaling never reached the destination, or it was rejected somewhere along the way. RTP never even gets a chance to start because SIP didn't set up the session.

Understanding which protocol is responsible for which part of the call is the foundation everything else in this series builds on.

## Where SIP came from

SIP was designed in the mid 1990s by the Internet Engineering Task Force, the same group responsible for most of the core internet protocols. It was formally specified in RFC 2543 in 1999 and significantly revised in RFC 3261 in 2002, which is the version that essentially defines modern SIP.

The designers of SIP made a deliberate choice to model it after HTTP, the protocol that powers the web. This wasn't an accident. HTTP had proven that a simple, text based request/response protocol could scale to enormous adoption. The SIP designers wanted the same characteristics: human readable messages, a familiar request/response pattern, and extensibility through headers.

This design decision has real practical consequences. Because SIP messages are plain text, you can read them. Open a packet capture of SIP traffic and you'll see actual words, not binary data that needs specialized decoding. You'll see "INVITE" when someone is placing a call. You'll see "200 OK" when the other end answers. You'll see phone numbers, IP addresses, and header names that mostly describe what they contain. This readability is what makes SIP troubleshooting possible without expensive proprietary tools.

The HTTP influence also shows up in the way SIP handles responses. SIP uses the same numeric response code scheme as HTTP. A 200 response means success, just like on the web. A 404 means the address wasn't found. A 500 means something broke on the server. If you've ever seen an HTTP status code, you already have a rough mental model for SIP responses. Our [SIP response code reference](/tools/sip-codes) covers every code you'll encounter in practice and what each one means for troubleshooting.

## SIP's role in a call

When you pick up a VoIP phone and dial a number, here's what SIP is responsible for:

**Finding the destination.** SIP takes the number you dialed and figures out where to send the call. This might involve querying a registrar to find out where a particular extension is currently located, or routing the call through a proxy server that knows how to reach the outside world.

**Negotiating the terms.** Before any audio flows, the two endpoints need to agree on how they're going to communicate. What audio codec will they use? What IP addresses and ports will they send audio to? This negotiation happens through SDP (Session Description Protocol), which travels inside SIP messages. We'll cover SDP in detail in [post 5](/blog/sdp-media-negotiation).

**Establishing the session.** SIP manages the handshake that both parties agree to. The caller says "I want to talk." The callee says "OK, I accept." SIP carries these messages back and forth.

**Modifying the session if needed.** If someone presses the hold button, or if the call needs to be transferred to another party, SIP handles those changes to the session while it's in progress.

**Tearing down the session.** When someone hangs up, SIP carries the "goodbye" message and ensures both sides know the call is over.

That's it. Everything else, the actual voice audio, is handled by RTP. Once SIP has set up the session and the two sides know where to send audio, SIP's job is largely done until something needs to change or the call ends.

## The key players

SIP involves several types of entities, and understanding their roles helps make sense of how calls flow through a network.

A **User Agent (UA)** is anything that sends or receives SIP messages on behalf of a user. Your desk phone is a user agent. A softphone application on your computer is a user agent. The user agent that initiates a call is called the User Agent Client (UAC), and the one that receives it is the User Agent Server (UAS). These roles can switch during a single call: the phone that initiated the call becomes the UAS when the other end sends a request to it.

A **Proxy Server** is an intermediary that routes SIP messages between user agents. When your phone sends an INVITE, it usually doesn't send it directly to the other phone. It sends it to a proxy, which figures out where the call should go and forwards it. Proxies can chain together, with each one forwarding the message to the next hop. Your PBX (whether it's in your office or in the cloud) acts as a SIP proxy, among other things.

A **Registrar** is a server that handles registration. When your phone boots up and says "I'm extension 101, and you can reach me at this IP address," the registrar records that information. When someone calls extension 101, the system consults the registrar to find out where to send the call. In practice, the registrar function is usually built into the same server as the proxy.

A **Session Border Controller (SBC)** sits at the edge of a network and manages SIP traffic crossing network boundaries. SBCs handle security, NAT traversal, codec translation, and a bunch of other functions that we'll get into later in the series. Most SIP trunk providers put an SBC between their network and yours.

## Your first look at a SIP message

We'll tear apart SIP messages in detail starting in the next post, but here's a preview of what you'll be learning to read. This is an actual SIP INVITE, the message that initiates a call:

```
INVITE sip:bob@192.168.1.100:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@192.168.1.50
CSeq: 314159 INVITE
Contact: <sip:alice@192.168.1.50:5060>
Content-Type: application/sdp
Content-Length: 142

v=0
o=alice 2890844526 2890844526 IN IP4 192.168.1.50
s=Phone Call
c=IN IP4 192.168.1.50
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 opus/48000/2
```

Right now, that probably looks like a wall of somewhat cryptic text. By the end of the next post, you'll be able to read every line of it and know exactly what it's doing. By the end of this series, you'll be able to look at a sequence of these messages and diagnose why a call is failing.

That's where we're headed. Let's start taking it apart.

*Next up: [Anatomy of a SIP Message: Reading the Headers](/blog/anatomy-of-a-sip-message), where we take a single SIP message and walk through it line by line.*

---

### Part 2: Anatomy of a SIP Message: Reading the Headers

URL: https://voiptest.com/blog/anatomy-of-a-sip-message
Published: 2026-04-08
Tags: sip, sip-headers, voip, protocol-fundamentals

*SIP Signaling From the Wire Up: Part 2 of 12*

In the last post we established what SIP does at a high level: it handles the signaling that sets up, modifies, and tears down communication sessions. Now we're going to get our hands on an actual SIP message and go through it piece by piece. By the end of this post, you'll be able to look at a SIP message in a packet capture or a debug log and understand what every major header is doing.

## The structure of a SIP message

Every SIP message has the same basic structure: a start line, a set of headers, an empty line, and an optional body.

```
Start Line
Header: value
Header: value
Header: value

Body (optional)
```

The start line tells you what kind of message this is. The headers carry all the metadata about the message: who it's from, who it's going to, how to route it, how to track it. The body, when present, usually contains SDP (Session Description Protocol) data that describes the media session. We'll cover SDP in depth in [post 5](/blog/sdp-media-negotiation).

SIP messages come in two flavors: requests and responses. A request is something one party is asking another to do. A response is the answer to that request.

## Requests and responses

The start line of a request is called the Request-Line. It contains a method name (the action being requested), a Request-URI (where the request is going), and the SIP version:

```
INVITE sip:bob@example.com SIP/2.0
```

The method tells you what action is being performed. The most common methods are:

**INVITE** starts a new call or modifies an existing one.
**ACK** confirms that you received a final response to an INVITE.
**BYE** ends a call.
**CANCEL** cancels a pending INVITE (the phone is ringing but the caller hung up before the callee answered).
**REGISTER** tells the registrar where you are.
**OPTIONS** asks about capabilities (often used as a keep alive or health check).

The start line of a response is called the Status-Line. It contains the SIP version, a numeric status code, and a human readable reason phrase:

```
SIP/2.0 200 OK
```

We'll cover response codes in detail in [post 7](/blog/sip-response-codes). For now, just know that they work like HTTP: 1xx means provisional (in progress), 2xx means success, 3xx means redirection, 4xx means the request had a problem, 5xx means the server had a problem, and 6xx means a global failure.

## Taking apart a real INVITE

Let's look at a complete INVITE message, the kind you'd see in a packet capture when someone places a call. We'll go through each header and explain what it's doing and why it matters.

```
INVITE sip:bob@192.168.1.100:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: "Bob Smith" <sip:bob@example.com>
From: "Alice Jones" <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@10.0.0.50
CSeq: 1 INVITE
Contact: <sip:alice@10.0.0.50:5060>
Content-Type: application/sdp
Content-Length: 256
```

(The SDP body itself is omitted here; it's the 256 bytes the Content-Length header is counting.)

Let's take these one at a time.

### The Request-Line

```
INVITE sip:bob@192.168.1.100:5060 SIP/2.0
```

This tells us three things. The method is INVITE, meaning this is a request to start a call. The Request-URI is `sip:bob@192.168.1.100:5060`, which is the address the request is being sent to. And the SIP version is 2.0, which is the only version you'll encounter in practice.

The Request-URI is the address that controls routing. Proxy servers use this field to decide where to forward the message. As the message passes through proxies, the Request-URI may be rewritten to point to the next hop. The Request-URI in this example points to a specific IP address and port, which suggests this INVITE has already been routed and is heading directly to Bob's phone.

### Via

```
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK776asdhds
```

The Via header records the path the request has taken. Each server that handles the message adds its own Via header to the top of the stack. When the response comes back, each server peels off its Via header to route the response back along the exact same path.

This header tells us that the message was sent via UDP from 10.0.0.50 on port 5060. The transport could also be TCP, TLS, or WSS; [browser-based SIP clients](/blog/sip-and-websockets) carry the same messages over WebSocket connections. The `branch` parameter is a unique transaction identifier. Every new SIP transaction gets a new branch value, with the same two exceptions you'll meet again in the CSeq section: a CANCEL carries the same branch as the request it cancels, and an ACK for a non-2xx final response carries the same branch as the INVITE it acknowledges. If you're looking at a capture with many calls happening simultaneously, the branch value is one way to track which responses belong to which requests.

In a real world call that passes through one or more proxies, you'd see multiple Via headers stacked up, one for each hop. The topmost Via is always the server that handled the message most recently. The bottom Via is the original sender.

### Max-Forwards

```
Max-Forwards: 70
```

This is a loop prevention mechanism. Every proxy that forwards the message decrements this value by one. If it reaches zero, the request is rejected and a 483 Too Many Hops response is sent back. The default starting value under [RFC 3261's rule for Max-Forwards](https://www.rfc-editor.org/rfc/rfc3261) is 70, which is more than enough for any legitimate routing path. If you see a 483 response in a trace, you've got a routing loop somewhere in your infrastructure.

### To

```
To: "Bob Smith" <sip:bob@example.com>
```

The To header identifies the logical recipient of the request. Here's the counterintuitive part: the To header is not used for routing. The Request-URI handles routing. The To header is an identifier that stays constant throughout the dialog. Once the callee responds, a tag parameter gets added to the To header, and the combination of Call-ID, From tag, and To tag uniquely identifies this specific call dialog.

The display name ("Bob Smith") is purely informational. It's what might show up on a screen somewhere, but it has no protocol significance.

### From

```
From: "Alice Jones" <sip:alice@example.com>;tag=1928301774
```

The From header identifies the logical sender. Like the To header, it's an identifier, not a routing directive. The `tag` parameter is generated by the sender and is unique for this call. Combined with the Call-ID and the To tag (added later by the callee), these three values create a globally unique dialog identifier.

An important note: the From header is [not a reliable indicator of the caller's actual identity](https://www.rfc-editor.org/rfc/rfc8224). It can be set to anything. This is why caller ID spoofing is possible. The From header might say one thing while the actual source of the call is something entirely different. We'll touch on this more in the security post later in the series.

### Call-ID

```
Call-ID: a84b4c76e66710@10.0.0.50
```

The Call-ID is a globally unique identifier for this dialog. It's generated by the calling party and stays the same for every SIP message in the dialog, from the initial INVITE through every provisional response, the final response, the ACK, and eventually the BYE. When you're reading a packet capture with dozens of calls happening simultaneously, Call-ID is how you filter down to the specific call you're investigating.

One caveat for real-world captures: "the same for the whole call" holds within a single dialog, but many devices in the middle of a call path (SBCs and most PBXes) are back-to-back user agents (B2BUAs, cataloged in [RFC 7092](https://www.rfc-editor.org/rfc/rfc7092)) rather than proxies. A B2BUA terminates the dialog on one side and originates a new one on the other, so the same phone call can have a different Call-ID (and different tags, Via, and Contact headers) on each leg. If you're capturing on both sides of an SBC, don't expect one Call-ID to match end to end.

The format is typically a random string followed by @ and the sender's host. Different implementations generate the random portion differently, but the goal is uniqueness.

### CSeq

```
CSeq: 1 INVITE
```

CSeq stands for Command Sequence. It contains a sequence number and the method name. The sequence number can start at almost any value (per RFC 3261 the initial value is arbitrary, though it must fit in a 32-bit unsigned integer and stay below 2^31), and it increments with each new request the party sends within a dialog. If the call is later modified with a re-INVITE, the CSeq number increments. A subsequent BYE increments it again.

Two methods break the "every new request increments" pattern, and RFC 3261 is explicit about both: an ACK carries the same CSeq number as the INVITE it acknowledges (with the method changed to ACK), and a CANCEL carries the same CSeq number as the request it's cancelling. When you see `CSeq: 1 INVITE`, `CSeq: 1 ACK`, and `CSeq: 1 CANCEL` in a trace, that's not a numbering bug; it's how those methods are tied back to their INVITE.

CSeq serves two purposes. First, it lets the recipient match a response to its request. A response to the INVITE will have the same CSeq value and method. A response to a later BYE will carry the BYE's CSeq value. Second, it provides ordering. If two requests arrive out of order, CSeq tells the recipient which one came first.

### Contact

```
Contact: <sip:alice@10.0.0.50:5060>
```

The Contact header contains the address where the sender wants to receive subsequent requests within this dialog. This is different from both the From header and the Via header. The From header is a logical identity. The Via header is for routing responses to this specific request. The Contact header is for routing future requests in the ongoing dialog.

This is the header that causes a lot of NAT problems. The phone sets its Contact address to its local IP, which might be a private address like 10.0.0.50. The remote end sees that address and tries to send subsequent messages to it, which fails if the phone is behind NAT and the private address isn't reachable from the outside. We'll cover this in depth in the [NAT post](/blog/sip-nat-traversal).

### Content-Type and Content-Length

```
Content-Type: application/sdp
Content-Length: 256
```

These headers describe the message body. Content-Type tells us the body is SDP, which is by far the most common body type in SIP messages. Content-Length tells us how many bytes the body contains. Not every SIP message has a body. A BYE, for example, typically doesn't include SDP because there's no media negotiation happening. An INVITE almost always includes SDP because it needs to propose the terms of the media session.

## How a response mirrors the request

When Bob's phone receives this INVITE and starts ringing, it sends back a 180 Ringing response. The response looks like this:

```
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK776asdhds
To: "Bob Smith" <sip:bob@example.com>;tag=a6c85cf
From: "Alice Jones" <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@10.0.0.50
CSeq: 1 INVITE
Contact: <sip:bob@192.168.1.100:5060>
Content-Length: 0
```

Notice that the Via, From, Call-ID, and CSeq are identical to the request. This is how you match a response to the request that triggered it. The To header now has a tag added by Bob's phone (`tag=a6c85cf`). The Contact header shows Bob's address. And the Content-Length is 0 because a 180 Ringing doesn't carry an SDP body.

## The dialog identifier

At this point, with both the From tag from Alice and the To tag from Bob, plus the Call-ID, we have a complete dialog identifier:

- Call-ID: `a84b4c76e66710@10.0.0.50`
- From tag: `1928301774`
- To tag: `a6c85cf`

This combination uniquely identifies this specific call dialog. Every subsequent message between Alice and Bob for this call will carry these same three values. If you're searching through a capture for all the messages related to a single call, these three fields are your filter.

## What this looks like in practice

In a debug log or a [Wireshark capture](/blog/reading-a-sip-trace), SIP messages appear as blocks of text. Being able to scan the first line (request or response), check the Call-ID (which call is this), check the CSeq (what request is this related to), and glance at the Via headers (what path did this take) is the fundamental skill of SIP troubleshooting. If you have a capture file and want to skip the manual parsing, the [SIP call stories tool](/tools/sip-call-stories) will walk through the flow for you. Everything else builds on this ability to orient yourself within a SIP message and understand what you're looking at.

Now that you can read individual messages, the next post puts them in sequence and walks through a complete call from start to finish.

*Next up: [Your First Call Flow: INVITE to BYE](/blog/first-call-flow-invite-to-bye), which follows a complete call through every SIP message from setup to hangup.*

---

### Part 3: Your First Call Flow: INVITE to BYE

URL: https://voiptest.com/blog/first-call-flow-invite-to-bye
Published: 2026-04-09
Tags: sip, call-flow, voip, invite, troubleshooting

*SIP Signaling From the Wire Up: Part 3 of 12*

You can now read individual SIP messages and understand what the major headers do. The next step is seeing how those messages fit together in sequence. A phone call isn't a single message. It's a conversation between SIP entities, a series of requests and responses that follow a specific pattern. Understanding this pattern is what lets you look at a packet capture and say "this is where the call went wrong."

This post walks through a complete basic call, from the moment someone dials a number to the moment someone hangs up. We'll show every SIP message in the sequence, explain why each one exists, and point out the things you should pay attention to when you see these in a trace.

## The players

For this example, we have three entities:

- **Alice's phone** (10.0.0.50), the caller
- **Proxy server** (10.0.0.1), the PBX or SIP proxy handling call routing
- **Bob's phone** (192.168.1.100), the callee

In a real deployment, there might be more hops (an SBC, a SIP trunk provider, another proxy on the far side), but the fundamental message pattern is the same regardless of how many intermediaries are involved. Two simplifications in this example are worth flagging up front. First, Alice sits on 10.0.0.0/8 and Bob on 192.168.0.0/16, two private address ranges. For this flow to work as drawn, we're assuming both subnets are routable to each other (the same enterprise network, or connected by VPN). Endpoints on private addresses behind separate NATs cannot exchange packets directly like this; they need [ICE (RFC 8445)](https://www.rfc-editor.org/rfc/rfc8445), a media relay, or an SBC in the path; that's the subject of the [NAT post](/blog/sip-nat-traversal). Second, our proxy is a true RFC 3261 proxy that forwards messages unmodified apart from routing headers. Many real "proxies" (SBCs, most PBXes) are back-to-back user agents (RFC 7092) that terminate the dialog and create a new one, rewriting Call-ID, tags, Contact, and the SDP addresses between legs.

## The call flow

Here's the complete sequence. We'll go through each step.

```
Alice                    Proxy                    Bob
  |                        |                        |
  |------- INVITE -------->|                        |
  |<----- 100 Trying ------|                        |
  |                        |------- INVITE -------->|
  |                        |<----- 180 Ringing -----|
  |<----- 180 Ringing -----|                        |
  |                        |<------ 200 OK ---------|
  |<------ 200 OK ---------|                        |
  |-------- ACK ---------> (directly to Bob or via proxy)
  |                        |                        |
  |<== RTP audio flows directly between Alice and Bob ==>|
  |                        |                        |
  |--------------------- BYE ---------------------->|
  |<-------------------- 200 OK --------------------|
  |                        |                        |
```

### Step 1: Alice sends INVITE

Alice picks up her phone and dials Bob's number. Her phone constructs an INVITE message and sends it to the proxy:

```
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
To: <sip:bob@example.com>
From: "Alice" <sip:alice@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@10.0.0.50
CSeq: 1 INVITE
Contact: <sip:alice@10.0.0.50:5060>
Content-Type: application/sdp
Content-Length: 200

v=0
o=alice 2890844526 2890844526 IN IP4 10.0.0.50
s=Call
c=IN IP4 10.0.0.50
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 opus/48000/2
a=sendrecv
```

The Request-URI is `sip:bob@example.com`, which is a logical address. Alice's phone doesn't know Bob's IP address. That's the proxy's job to figure out. The [SDP body](/blog/sdp-media-negotiation) at the bottom contains Alice's media proposal: she can do G.711 mu-law (PCMU), G.711 A-law (PCMA), or Opus, and she wants to receive audio on port 49170 at her IP address 10.0.0.50.

### Step 2: Proxy sends 100 Trying

The proxy receives the INVITE, and the first thing it does is send back a 100 Trying:

```
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK74bf9
To: <sip:bob@example.com>
From: "Alice" <sip:alice@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@10.0.0.50
CSeq: 1 INVITE
Content-Length: 0
```

The 100 Trying says "I got your INVITE and I'm working on it." This is a hop by hop response. It stops Alice's phone from retransmitting the INVITE (since SIP over UDP has no built in delivery confirmation, the sender will keep resending until it gets a response). The 100 Trying does not mean the call is going to succeed. It just means the proxy acknowledged receipt.

### Step 3: Proxy forwards INVITE to Bob

The proxy looks up Bob's registration (to find out where Bob's phone currently is) and forwards the INVITE:

```
INVITE sip:bob@192.168.1.100:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bK2d4790
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK74bf9
Max-Forwards: 69
To: <sip:bob@example.com>
From: "Alice" <sip:alice@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@10.0.0.50
CSeq: 1 INVITE
Contact: <sip:alice@10.0.0.50:5060>
Content-Type: application/sdp
Content-Length: 200

[same SDP body as before]
```

Notice two changes. First, the Request-URI has been rewritten to `sip:bob@192.168.1.100:5060`, which is Bob's actual network address from his registration. This is the proxy doing its job: translating a logical address into a physical one. Second, a new Via header has been added at the top for the proxy. The original Via from Alice is still there underneath. Max-Forwards has been decremented by one.

### Step 4: Bob's phone rings, sends 180 Ringing

Bob's phone receives the INVITE, determines that it can accept the call, and starts ringing. It sends back a 180 Ringing:

```
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bK2d4790
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK74bf9
To: <sip:bob@example.com>;tag=a6c85cf
From: "Alice" <sip:alice@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@10.0.0.50
CSeq: 1 INVITE
Contact: <sip:bob@192.168.1.100:5060>
Content-Length: 0
```

The 180 Ringing tells Alice's phone to play a ringback tone (the sound you hear while waiting for someone to pick up). Note that Bob's phone has added a tag to the To header (`tag=a6c85cf`). Now we have both tags and the complete dialog identifier exists.

The proxy receives this response, peels off the top Via header (its own), and forwards the 180 to Alice's phone using the remaining Via.

### Step 5: Bob answers, sends 200 OK

Bob picks up the phone. His phone sends a 200 OK with an SDP body containing Bob's media answer:

```
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bK2d4790
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK74bf9
To: <sip:bob@example.com>;tag=a6c85cf
From: "Alice" <sip:alice@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@10.0.0.50
CSeq: 1 INVITE
Contact: <sip:bob@192.168.1.100:5060>
Content-Type: application/sdp
Content-Length: 152

v=0
o=bob 2808844564 2808844564 IN IP4 192.168.1.100
s=Call
c=IN IP4 192.168.1.100
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendrecv
```

Bob's [SDP answer](https://www.rfc-editor.org/rfc/rfc3264) selects PCMU (G.711 mu-law) from Alice's list of offered codecs and provides his own IP address and port for receiving audio (192.168.1.100 port 3456). Both sides now have all the information they need to start sending RTP audio to each other.

The proxy forwards the 200 OK to Alice, again stripping its own Via header in the process.

### Step 6: Alice sends ACK

Alice's phone receives the 200 OK and sends an ACK to confirm:

```
ACK sip:bob@192.168.1.100:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK74bf10
Max-Forwards: 70
To: <sip:bob@example.com>;tag=a6c85cf
From: "Alice" <sip:alice@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@10.0.0.50
CSeq: 1 ACK
Content-Length: 0
```

The ACK is the third part of [a three way handshake that's unique to INVITE](https://www.rfc-editor.org/rfc/rfc3261). No other SIP method uses this pattern. The reason it exists is reliability. SIP often runs over UDP, which provides no delivery guarantee. The 200 OK to an INVITE is critically important (it commits both sides to the call and triggers resource allocation), so there needs to be a positive confirmation that the caller received it. If Bob's phone sends a 200 OK and never gets an ACK, it knows the 200 didn't arrive and can retransmit.

### Step 7: Audio flows (RTP, not SIP)

At this point, SIP's job is done for now. Alice and Bob are talking. The audio travels as RTP packets between Alice's phone (10.0.0.50 port 49170) and Bob's phone (192.168.1.100 port 3456), at the addresses each side advertised in its SDP, and, crucially, without passing through the proxy, which only ever handled the signaling. Remember the topology assumption from earlier: this direct media path only exists because we've stipulated that these two private subnets can route to each other. Across separate NATs, the addresses in the SDP would be unreachable and the media would have to be established via [ICE (RFC 8445)](https://www.rfc-editor.org/rfc/rfc8445) or relayed. Either way, there are no SIP messages during the conversation unless something changes, like a hold or transfer.

### Step 8: Alice hangs up, sends BYE

Alice ends the call. Her phone sends a BYE:

```
BYE sip:bob@192.168.1.100:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK74bf11
Max-Forwards: 70
To: <sip:bob@example.com>;tag=a6c85cf
From: "Alice" <sip:alice@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@10.0.0.50
CSeq: 2 BYE
Contact: <sip:alice@10.0.0.50:5060>
Content-Length: 0
```

Notice that CSeq has incremented to 2, and the method is now BYE. Same Call-ID, same tags. This is still the same dialog.

Notice also where the BYE goes: straight to Bob's Contact address (`sip:bob@192.168.1.100:5060`), not through the proxy. Our proxy never inserted a Record-Route header when it forwarded the INVITE in Step 3, so it dropped out of the conversation once the call was established: in-dialog requests go directly to the address the other side advertised in its Contact header. A proxy that wants to stay in the signaling path for the whole call inserts Record-Route, and then you would see the BYE at the proxy too.

### Step 9: Bob responds with 200 OK

Bob's phone acknowledges the BYE:

```
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK74bf11
To: <sip:bob@example.com>;tag=a6c85cf
From: "Alice" <sip:alice@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@10.0.0.50
CSeq: 2 BYE
Content-Length: 0
```

The call is now complete. Both sides stop sending RTP. The dialog is terminated. Notice that BYE uses a simple two message exchange (BYE, 200 OK), not the three way handshake that INVITE uses. The ACK is only for INVITE.

## What about CANCEL?

There's one more scenario worth covering. What happens if Alice hangs up while Bob's phone is still ringing, before he answers? Alice can't send BYE because the dialog isn't fully established yet (no 200 OK was received). Instead, she sends CANCEL:

```
CANCEL sip:bob@192.168.1.100:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK74bf9
To: <sip:bob@example.com>
From: "Alice" <sip:alice@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@10.0.0.50
CSeq: 1 CANCEL
Content-Length: 0
```

The CANCEL uses the same branch value as the original INVITE because it's cancelling that specific transaction. Bob's phone responds with a 200 OK to the CANCEL (acknowledging it received the cancellation) and then sends a 487 Request Terminated for the original INVITE (indicating that the INVITE was cancelled before it could be answered).

## Why this matters for troubleshooting

When you're looking at a SIP trace of a failed call, the first thing to do is find the call flow and see where it deviates from this normal pattern. A call that never gets past the INVITE (no 100 Trying, no 180 Ringing) has a routing problem or the INVITE is being dropped by a [firewall](/blog/sip-nat-traversal). A call that rings but never connects (180 Ringing comes back, but no 200 OK and no error response) might have a problem on the callee's end. If the trace ends with an unfamiliar response code, the [SIP response code reference](/tools/sip-codes) can help you narrow down the cause. A call that connects (200 OK received) but then drops immediately might have an ACK delivery problem.

Knowing what the normal flow looks like is the foundation for recognizing when something is abnormal. For a symptom-based reference of what deviations from this pattern mean in practice, see [Common SIP Problems and What They Look Like](/blog/common-sip-problems).

*Next up: [SIP Registration: How Your Phone Tells the World Where It Is](/blog/sip-registration), covering what happens when a phone boots up and announces itself to the network.*

---

### Part 4: SIP Registration: How Your Phone Tells the World Where It Is

URL: https://voiptest.com/blog/sip-registration
Published: 2026-04-10
Tags: sip, registration, voip, authentication, troubleshooting

*SIP Signaling From the Wire Up: Part 4 of 12*

When an IP phone powers on, nobody knows where it is. Unlike a traditional phone that's wired directly to a port in a switch closet, an IP phone could be anywhere on any network. It could be at a desk in the main office, plugged in at a branch location, or connected through a VPN from someone's home. The phone needs a way to announce itself to the system and say "I'm extension 200, and right now you can reach me at this IP address and port." That announcement is SIP registration.

Registration is one of the first things that happens when a phone boots up, and it's one of the most common failure points in VoIP systems. If registration fails, the phone can't receive calls. In many setups it can't make calls either. Understanding how registration works at the protocol level makes it much easier to diagnose why a phone is showing "not registered" on its screen or why [calls for a particular extension are going straight to voicemail](/blog/calls-going-to-voicemail).

## What registration does

SIP registration creates a binding between an address of record (AOR) and a contact address. The address of record is the phone's logical identity, something like `sip:alice@example.com`. The contact address is the phone's current physical location on the network, something like `sip:alice@10.0.0.50:5060`.

The registrar server stores this binding. When someone calls `sip:alice@example.com`, the proxy looks up the current binding in the registrar and knows to send the INVITE to `10.0.0.50:5060`. If Alice moves her phone to a different network and re-registers from a new IP address, the binding updates and calls get routed to the new address. This is what allows IP phones to be portable in a way that traditional phones aren't. The same mechanism applies to [browser-based softphones](/blog/sip-and-websockets), which send the identical REGISTER exchange over a WebSocket connection instead of UDP.

## The registration flow

Registration involves a challenge/response authentication sequence. Here's how it plays out.

### Step 1: Initial REGISTER (unauthenticated)

The phone sends a REGISTER to the registrar:

```
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: "Alice" <sip:alice@example.com>
From: "Alice" <sip:alice@example.com>;tag=456248
Call-ID: 843817637684230@10.0.0.50
CSeq: 1 REGISTER
Contact: <sip:alice@10.0.0.50:5060>
Expires: 3600
Content-Length: 0
```

A few things to note. The Request-URI is `sip:example.com`, which is the domain of the registrar. Unlike an INVITE, which is addressed to a specific user, REGISTER is addressed to the domain. The To and From are both Alice, because she's registering herself. The Contact header contains the address where Alice wants to be reached. The Expires header says Alice wants this registration to be valid for 3600 seconds (one hour).

### Step 2: Server challenges with 401 Unauthorized

The registrar doesn't just accept registrations from anyone. It needs to verify that this is actually Alice and not someone pretending to be her. (We cover the full [authentication and security model](/blog/sip-authentication-security) later in the series.) So it rejects the initial REGISTER with a 401 Unauthorized and includes a challenge:

```
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bKnashds7
To: "Alice" <sip:alice@example.com>;tag=2145
From: "Alice" <sip:alice@example.com>;tag=456248
Call-ID: 843817637684230@10.0.0.50
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="example.com",
  nonce="84a4cc6f3082121f32b42a2187831a9e",
  qop="auth",
  algorithm=MD5
Content-Length: 0
```

The WWW-Authenticate header is the challenge. It contains a `realm` (the authentication domain), a `nonce` (a server-generated value that the client must fold into its hash), and the algorithm to use. A common simplification is to call the nonce a one-time value, but RFC 3261 doesn't require that: servers choose their own nonce policy, and many issue nonces that remain valid for a window of time or a number of uses, marking an expired one with `stale=true` so the client re-authenticates without re-prompting for a password. The actual replay protection in this exchange comes from the `qop="auth"` directive: it obligates the client to include a nonce count (`nc`) and a client nonce (`cnonce`) in its response, so even two requests under the same server nonce produce different hashes and a captured response can't simply be replayed.

### Step 3: Phone re-registers with credentials

The phone takes the challenge parameters, combines them with Alice's username and password using the specified algorithm, and generates a digest response. It sends a new REGISTER with the Authorization header:

```
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bKnashds8
Max-Forwards: 70
To: "Alice" <sip:alice@example.com>
From: "Alice" <sip:alice@example.com>;tag=456248
Call-ID: 843817637684230@10.0.0.50
CSeq: 2 REGISTER
Contact: <sip:alice@10.0.0.50:5060>
Expires: 3600
Authorization: Digest username="alice",
  realm="example.com",
  nonce="84a4cc6f3082121f32b42a2187831a9e",
  uri="sip:example.com",
  response="dfe56131d1958046689cd83306477ecc",
  algorithm=MD5,
  qop=auth,
  nc=00000001,
  cnonce="0a4f113b"
Content-Length: 0
```

The CSeq has incremented to 2 (this is a new request), and the branch is different (new transaction), but the Call-ID and tags are the same. Note that REGISTER does not create a dialog. The reuse of Call-ID and From tag here is for correlating the registration sequence (allowing the server to associate the authenticated retry with the original challenge), not for dialog maintenance. This is different from INVITE, where those values identify an ongoing dialog between two parties.

The Authorization header contains the digest `response`, which is the hash value computed from Alice's credentials and the challenge parameters, including the `nc` and `cnonce` values required by `qop=auth`. The server performs the same computation using the password it has stored for Alice. If the results match, Alice is authenticated. Because the `nc` counter increments with each use of a nonce, the server can also detect a replayed request even when it allows the same nonce to be used more than once.

Note that the password itself never appears in the message. Only the computed hash is transmitted. This means that capturing a REGISTER from the network doesn't directly expose the password, though MD5 digest is considered legacy by modern standards (RFC 8760 defines SHA-256 and SHA-512/256 digest for SIP) and the hash can potentially be brute forced offline if the password is short or common.

### Step 4: Server accepts with 200 OK

If the credentials check out, the registrar stores the binding and sends a 200 OK:

```
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bKnashds8
To: "Alice" <sip:alice@example.com>;tag=2145
From: "Alice" <sip:alice@example.com>;tag=456248
Call-ID: 843817637684230@10.0.0.50
CSeq: 2 REGISTER
Contact: <sip:alice@10.0.0.50:5060>;expires=3600
Content-Length: 0
```

The Contact header in the response confirms the binding and the expiration time. Alice is now registered. The registrar knows that calls for `sip:alice@example.com` should be routed to `10.0.0.50:5060`.

## Registration lifetime and re-registration

The Expires value in the registration defines how long the binding is valid. When Alice registered with Expires: 3600, the registrar will keep her binding for one hour. If Alice doesn't re-register before that hour is up, the binding expires and she becomes unreachable.

In practice, phones re-register well before the expiration. A phone with a 3600 second registration lifetime might re-register every 1800 or 2700 seconds. The exact behavior varies by phone manufacturer and configuration. The re-registration process is the same as the initial registration: the phone sends a REGISTER, gets challenged, responds with credentials, and gets a new 200 OK with a refreshed expiration.

If re-registration fails for any reason, the phone has a limited window before the existing registration expires. If that window passes without a successful re-registration, the phone drops off the system. Incoming calls fail. The phone shows "not registered" or a similar status.

This is why intermittent registration failures can cause intermittent call problems. The phone might be registered and working, then fail to re-register during one cycle, remain reachable for the remaining lifetime of the old registration, and then lose registration entirely. A few minutes later, the next re-registration attempt might succeed, and everything works again. To the user, it looks like the phones randomly stop working for a few minutes at a time.

## What the server can do with Expires

The server doesn't have to accept the client's requested expiration time. It can shorten it. If Alice asks for 3600 seconds but the server's policy is a maximum of 600 seconds, the 200 OK will come back with `expires=600` in the Contact header. The phone should respect this and re-register within 600 seconds.

Some servers set very short expiration times as a way to keep tighter control over registrations or to detect failed phones faster. The tradeoff is more registration traffic on the network and more load on the registrar. Very short expirations (under 60 seconds) over unreliable connections, particularly through certain NAT devices that have short UDP timeout values, can cause a cycle of registration, expiry, re-registration that creates instability.

## Unregistration

A phone can explicitly unregister by sending a REGISTER with `Expires: 0`:

```
REGISTER sip:example.com SIP/2.0
...
Contact: <sip:alice@10.0.0.50:5060>
Expires: 0
```

This tells the registrar to remove the binding immediately. A cleanly powered down phone should send this. In practice, not all phones do, especially if they lose power unexpectedly. In that case, the registrar just waits for the existing binding to expire naturally.

A phone can also send a REGISTER with `Contact: *` and `Expires: 0`, which removes all bindings for that address of record, not just the one from the current location. This is useful when a phone has been moved and old stale bindings need to be cleaned up.

## Common registration problems

**Wrong credentials.** The phone sends a REGISTER, gets challenged, sends the digest response, and gets a 403 Forbidden. The username or password is wrong. In the trace, you'll see the initial 401, the authenticated REGISTER, and then a 403 instead of a 200. Some servers send 401 again instead of 403 when credentials are wrong, which means the phone will keep trying the same bad credentials in an infinite loop of challenge/response failures.

**Firewall blocking.** The REGISTER leaves the phone but never reaches the registrar, or the 401 challenge comes back but the authenticated re-register gets blocked. In the trace from the phone's perspective, you'll see the REGISTER go out and then nothing. The phone retransmits several times and eventually gives up. From the server's perspective, it either never received the REGISTER at all, or it sent the 401 and never got the authenticated follow-up.

**DNS failure.** The phone is configured with a domain name for the registrar (e.g., `sip.example.com`) but can't resolve it to an IP address. The REGISTER never gets sent because the phone can't determine where to send it. This won't show up in a SIP trace at all because no SIP messages are generated. You'd see it in the phone's own logs as a DNS resolution error.

**NAT timeout.** The phone registers successfully through a NAT device, but the NAT device's UDP mapping expires before the next re-registration. When a new inbound call arrives, the registrar tries to send the INVITE to the Contact address it has on file, but the NAT mapping is gone, so the INVITE never reaches the phone. The phone's registration appears valid on the server, but it's effectively unreachable. This is one of the most frustrating problems to diagnose because the registration looks fine from both sides. We'll cover NAT issues extensively in [post 6](/blog/sip-nat-traversal).

**Server unreachable.** The registrar is down, overloaded, or the network path between the phone and the registrar is broken. The phone sends REGISTERs that go unanswered. After the existing registration expires, the phone is offline.

## What to look for in a trace

When troubleshooting a registration problem, filter your capture for REGISTER messages from the phone's IP address. You're looking for the sequence: REGISTER, 401, REGISTER with Authorization, and then the final response. If the final response is 200 OK, registration succeeded. If it's a 403 or another 401, there's an authentication problem. If there's no response at all after the initial REGISTER, there's a network or firewall issue.

Check the Expires value in the 200 OK to see how long the registration is valid. Check the Contact address to see what IP and port the server has recorded. If that Contact shows a private IP address and the phone is behind NAT, inbound calls may not work even though registration looks successful from the server's perspective.

*Next up: [SDP and Media Negotiation: How Two Phones Agree on How to Talk](/blog/sdp-media-negotiation), where we take apart the message body that determines what the call will actually sound like.*

---

### Part 5: SDP and Media Negotiation: How Two Phones Agree on How to Talk

URL: https://voiptest.com/blog/sdp-media-negotiation
Published: 2026-04-11
Tags: sip, sdp, codecs, media-negotiation, voip

*SIP Signaling From the Wire Up: Part 5 of 12*

SIP handles the signaling. RTP handles the audio. But before any audio can flow, the two endpoints need to agree on a set of parameters: what codec to use, what IP addresses to send audio to, what ports to listen on, and which direction the audio should flow. This negotiation happens through SDP, the Session Description Protocol, which rides inside the body of SIP messages.

If you've been following the call flow examples in this series, you've already seen SDP. It's the block of text at the bottom of an INVITE or a 200 OK that starts with `v=0`. This post takes that block apart line by line, because SDP is where most media problems become visible. If the audio isn't working, the answer is almost always in the SDP.

## Where SDP appears in the call flow

SDP uses an offer/answer model. The caller includes an SDP offer in the INVITE, describing what codecs it supports and where it wants to receive media. The callee includes an SDP answer in the 200 OK, selecting from the offered codecs and providing its own media receiving address.

After both sides have exchanged SDP, each one knows the other's IP address, port, and chosen codec. RTP can start flowing.

SDP can also appear in re-INVITEs (used for hold, transfer, and session changes) and occasionally in 183 Session Progress responses (used for early media, like playing a ringback tone or an IVR prompt before the call is fully answered).

## Taking apart an SDP offer

Here's a complete SDP body from an INVITE:

```
v=0
o=alice 2890844526 2890844526 IN IP4 10.0.0.50
s=Call
c=IN IP4 10.0.0.50
t=0 0
m=audio 49170 RTP/AVP 0 8 18 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:97 opus/48000/2
a=fmtp:18 annexb=no
a=ptime:20
a=sendrecv
```

Let's go through each line.

### v=0

Protocol version. This is always 0. It has been 0 since SDP was created and will likely remain 0 forever. It's there because the specification says there has to be a version field. You can ignore it.

### o=alice 2890844526 2890844526 IN IP4 10.0.0.50

The origin line. It identifies who created this session description. The fields are: username (`alice`), session ID (`2890844526`), session version (`2890844526`), network type (`IN` for internet), address type (`IP4`), and the originator's IP address.

The session version is the important part here. When SDP is used in a re-INVITE to modify a session, the session version must be incremented. The recipient uses this to determine whether the SDP has actually changed from the previous offer. If you're debugging a hold or transfer issue and the re-INVITE's SDP has the same session version as the original, some endpoints will ignore it because they think nothing changed.

### s=Call

The session name. Required by the spec but essentially meaningless in VoIP. It might say "Call," "Phone Call," "SIP Call," or just a dash. Nobody looks at this field for any practical purpose.

### c=IN IP4 10.0.0.50

The connection information line. This is one of the most important lines in the entire SDP. It specifies the IP address where the sender wants to receive media. This is the address that the remote end will use as the destination for RTP packets.

If this line contains a private IP address (like 10.x.x.x, 172.16.x.x through 172.31.x.x, or 192.168.x.x) and the remote end is on a different network, the RTP packets will never arrive. This is the most visible symptom of the [NAT traversal](/blog/sip-nat-traversal) problem that we'll cover in the next post.

### t=0 0

Timing. The two zeros mean the session is not bounded by a specific start and end time. In VoIP, this is always `t=0 0`. The field exists because SDP was originally designed for multimedia session announcements that might have scheduled start and end times, but phone calls don't work that way.

### m=audio 49170 RTP/AVP 0 8 18 97

The media description line. This is the other critically important line. Let's break it down:

- `audio` is the media type (as opposed to video, text, or application)
- `49170` is the port number where this endpoint wants to receive RTP packets
- `RTP/AVP` is the transport protocol (RTP using the Audio/Video Profile)
- `0 8 18 97` are the payload type numbers for the codecs being offered

Those payload type numbers are defined by IANA for standard codecs and by the sender for dynamic codecs. The standard ones are: 0 = PCMU (G.711 mu-law), 8 = PCMA (G.711 A-law), 18 = G.729. Payload type 97 is dynamically assigned, and you need to look at the `a=rtpmap` line to find out what it represents.

The order of the payload types matters. It indicates the sender's preference, most preferred first. In this case, Alice prefers PCMU, then PCMA, then G.729, then whatever codec 97 turns out to be. What the answerer does with that list is often misstated. Under the offer/answer rules (RFC 3264), the answer must use a subset of the formats from the offer, but it is not required to pick exactly one: an answer can retain multiple formats, and either endpoint may then switch among the negotiated formats during the session, subject to the payload format rules. Many implementations do answer with a single codec, usually the first one from the offer they support, which is why the one-codec answer looks like the rule. It's common practice, not a protocol requirement.

### a=rtpmap lines

```
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:97 opus/48000/2
```

The `rtpmap` attribute maps payload type numbers to codec names and clock rates. For the standard payload types (0, 8, 18), these lines are technically redundant because the mapping is well known. But including them is good practice because it removes any ambiguity.

The dynamic payload type 97 is mapped to `opus/48000/2`, which is the Opus codec. Don't read the `/2` as a promise of stereo audio: the Opus RTP payload specification (RFC 7587) requires the encoding to be declared as 48000 Hz with 2 channels regardless of what will actually be sent. Whether stereo is used is negotiated separately, through `fmtp` parameters like `stereo` and `sprop-stereo` and the endpoints' actual capabilities, and most voice calls carry mono despite the `/2`. Without this rtpmap line, the remote end would have no way to know what payload type 97 means.

### a=fmtp:18 annexb=no

The `fmtp` attribute provides format specific parameters. Here, it's saying that for G.729 (payload type 18), Annex B (silence suppression) should not be used. These parameters vary by codec and can affect interoperability if two sides have different expectations.

### a=ptime:20

The packetization time in milliseconds. This says each RTP packet should contain 20 milliseconds of audio. This is the most common value for VoIP. Some systems use 30 milliseconds. The value affects both bandwidth usage and how sensitive the call is to packet loss. Shorter ptime means more packets per second (more overhead but each lost packet represents less audio). Longer ptime means fewer packets but each lost packet takes a bigger chunk out of the conversation.

### a=sendrecv

The media direction attribute. `sendrecv` means this endpoint will both send and receive audio. This is the normal state for an active call. The other possible values are:

- `sendonly` means the endpoint will send audio but not receive it (used when putting someone on hold and playing hold music)
- `recvonly` means the endpoint will receive audio but not send it
- `inactive` means no audio in either direction

When you see the direction change in a re-INVITE's SDP, you're looking at a hold or unhold operation. We'll cover this in detail in [post 9](/blog/sip-call-features).

## The SDP answer

When Bob answers the call, his 200 OK includes an SDP answer:

```
v=0
o=bob 2808844564 2808844564 IN IP4 192.168.1.100
s=Call
c=IN IP4 192.168.1.100
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
a=sendrecv
```

The answer is simpler than the offer because a lot of the negotiation is resolved. Bob answered with PCMU (payload type 0) from Alice's list. He chose to list only that one codec in his media line; as noted above, an answer may retain several of the offered formats, but answering with a single codec pins the session down and is what many implementations do. He provided his own IP address (192.168.1.100) and port (3456) for receiving audio.

After this exchange, both sides know everything they need:

- Alice sends RTP to 192.168.1.100 port 3456, encoded as PCMU
- Bob sends RTP to 10.0.0.50 port 49170, encoded as PCMU

## When SDP negotiation fails

If the two endpoints can't find a common codec, the call fails. The callee sends a 488 Not Acceptable Here response instead of a 200 OK. In the trace, you'll see the INVITE with an SDP offer listing certain codecs, and then a 488 response indicating that none of those codecs are acceptable.

This happens most often when one side is configured for only G.729 and the other side doesn't have G.729 support, or when one side requires a specific codec that the other side hasn't been configured to offer. The fix is usually a configuration change on one or both endpoints to ensure they have at least one codec in common.

A subtler problem occurs when both sides agree on a codec in SDP but one side can't actually use it correctly. For example, G.729 is a licensed codec, and some implementations have a limited number of G.729 channels. If all channels are in use, the endpoint might negotiate G.729 in SDP but then fail to encode or decode the audio properly. The call connects, but the audio is garbled or silent. The SDP looks fine, which makes this problem harder to diagnose without checking the endpoint's codec licensing or channel capacity.

## Codec preference and transcoding

When a call passes through a PBX or SBC that bridges two different networks, the codec negotiation can get more complex. The PBX might negotiate one codec with the internal phone and a different codec with the SIP trunk provider. In this case, the PBX has to transcode, converting the audio from one codec format to another in real time.

Transcoding adds latency, uses CPU resources on the PBX, and can reduce audio quality (each encoding and decoding cycle introduces some degradation). Minimizing transcoding by ensuring that all endpoints and trunks support a common preferred codec is one of the easier optimizations you can make to improve call quality. (For more on how codec choice affects perceived quality, see [Understanding MOS Scores](/blog/understanding-mos-scores).)

If you're looking at a call quality problem on a call that traverses a PBX, check the SDP on both legs of the call. If the inbound leg negotiated Opus and the outbound leg negotiated G.711, the PBX is transcoding, and that could be contributing to quality issues, especially if the PBX is under heavy load. Uploading a packet capture to a [PCAP analyzer](/tools/pcap-analyzer) can extract and display the SDP from both legs side by side, making codec mismatches and addressing issues immediately visible.

---

*Next up: [NAT Traversal: Why SIP and NAT Don't Get Along](/blog/sip-nat-traversal), covering the reason one way audio exists and the collection of ugly hacks the industry built to work around it.*

---

### Part 6: NAT Traversal: Why SIP and NAT Don't Get Along

URL: https://voiptest.com/blog/sip-nat-traversal
Published: 2026-04-12
Tags: sip, nat, one-way-audio, stun, voip, troubleshooting

*SIP Signaling From the Wire Up: Part 6 of 12*

If there's a single topic that causes more real world SIP headaches than any other, it's NAT traversal. NAT, Network Address Translation, is how most networks share a single public IP address among multiple devices. It works transparently for web browsing, email, file downloads, and almost everything else on the internet. It does not work transparently for SIP and RTP, and the reasons why are directly responsible for an enormous percentage of VoIP problems, particularly the dreaded one way audio.

Understanding NAT traversal is arguably the most practically useful thing you can learn from this entire series. If you support VoIP systems in any capacity, you will encounter NAT problems. Knowing why they happen gives you a massive head start on fixing them.

## How NAT normally works

NAT sits on [your router](/blog/your-local-network) at the boundary between your private network and the public internet. When a device on your private network (say, 10.0.0.50) sends a packet to a server on the internet, the NAT device rewrites the source IP address in the packet header from 10.0.0.50 to the router's public IP address (say, 203.0.113.1). It also records this mapping in a table so that when the response comes back addressed to 203.0.113.1, the NAT device knows to forward it to 10.0.0.50 internally.

For protocols like HTTP, this is seamless. The web browser sends a request, NAT translates it, the server responds to the public address, NAT translates back, and the browser gets its response. The IP addresses embedded in the actual data payload don't matter because HTTP doesn't put network addresses in the body of its messages.

SIP does.

## Why SIP breaks through NAT

SIP embeds IP addresses in multiple places inside the message body and headers. Specifically:

1. The **Contact header** contains the sender's IP address and port where it wants to receive future requests
2. The **Via header** contains the sender's IP address
3. The **SDP body** contains the IP address and port where the sender wants to receive RTP audio (the `c=` line and the `m=` line)

When a phone behind NAT sends a SIP INVITE, the NAT device rewrites the source IP in the IP packet header, but it has no idea that there are also IP addresses embedded inside the SIP message body. Those embedded addresses remain unchanged as the phone's private IP.

Here's what that looks like in practice. Alice's phone is at private IP 10.0.0.50, behind a NAT device with public IP 203.0.113.1. She sends an INVITE to Bob's server:

**What the IP header says (after NAT):**
```
Source: 203.0.113.1 (the public IP -- NAT rewrote this)
Destination: 198.51.100.10 (Bob's server)
```

**What the SIP headers say (unchanged by NAT):**
```
Contact: <sip:alice@10.0.0.50:5060>
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK74bf9
```

**What the SDP body says (unchanged by NAT):**
```
c=IN IP4 10.0.0.50
m=audio 49170 RTP/AVP 0
```

Bob's server receives this INVITE. The SIP signaling works fine because responses can follow the IP header back to 203.0.113.1 (and the NAT device will forward them to Alice based on its mapping table). But when Bob's phone tries to send RTP audio, it looks at the SDP and sees "send audio to 10.0.0.50 port 49170." That's a private address. Bob's phone has no route to 10.0.0.50 because it's not on Alice's private network.

Result: the call connects successfully at the SIP layer. Bob can hear nothing from Alice because his RTP packets are going to an unreachable address. Meanwhile, Alice might be able to hear Bob because her phone knows Bob's correct address from his SDP. This is classic [one-way audio](/blog/one-way-audio), and it is overwhelmingly a NAT problem.

## The solutions

Over the years, the industry has developed several approaches to work around this fundamental incompatibility. None of them are elegant. They range from mostly adequate to actively harmful.

Before going through them, two framing points. First, there are really two separate problems hiding under "SIP and NAT": getting the *signaling* through (the Contact and Via addressing, and keeping the NAT pinhole open so inbound requests can reach the phone) and getting the *media* through (the addresses in the SDP that RTP actually flows to). A deployment can solve one without the other, which is exactly how you end up with a call that signals perfectly and has no audio. Second, none of these mechanisms is a universal fix that the protocol applies automatically. Which ones are in play is a deployment choice: the endpoint has to be configured for STUN or implement ICE, someone has to operate the TURN relay or SBC, and the provider's edge has to cooperate. Diagnosing a NAT issue starts with finding out which of these choices your deployment actually made.

### STUN (Session Traversal Utilities for NAT)

STUN is the simplest approach. The phone queries a STUN server on the public internet, which tells the phone what its public IP address and port look like from the outside. The phone then uses that public address in its SIP Contact header and SDP body instead of its private address.

A STUN exchange looks like this: the phone sends a binding request to the STUN server from its private address. The request passes through NAT, which assigns a public IP and port. The STUN server sees the request arriving from the public address and sends that address back to the phone. Now the phone knows its "reflexive" address, the public IP and port that NAT assigned.

```
Phone (10.0.0.50:5060) -> NAT -> STUN Server
                                      |
                    "You appear as 203.0.113.1:12345"
                                      |
Phone now uses 203.0.113.1:12345 in SIP/SDP
```

STUN works well in many common scenarios, but it's a per-endpoint configuration choice, not something the network provides on its own. It fails with symmetric NAT (address-and-port-dependent mapping, in [the vocabulary RFC 4787 introduced](https://www.rfc-editor.org/rfc/rfc4787.html) to replace the old cone/symmetric terms), where the NAT device assigns a different public port for each different destination. The port discovered via STUN (which was created for traffic to the STUN server) won't be the same port used for traffic to the SIP proxy, so the addresses in SIP/SDP are still wrong. Note also that STUN as typically deployed addresses the *media* addressing problem (the SDP) and sometimes the Contact header; it doesn't keep NAT mappings alive by itself.

### TURN (Traversal Using Relays around NAT)

TURN ([RFC 8656](https://www.rfc-editor.org/rfc/rfc8656.html)) is the fallback when STUN doesn't work. A TURN server acts as a relay. Instead of the two endpoints sending media directly to each other, both send their media to the TURN server, which forwards it. Because both endpoints initiate outbound connections to the TURN server (which works fine through NAT), the NAT problem is bypassed entirely, for whichever endpoints are actually configured to use that relay.

The downside is that every packet in the conversation goes through the relay, which adds latency, consumes bandwidth on the relay, and creates a single point of failure. TURN is used when there's no better option, not as a first choice.

### ICE (Interactive Connectivity Establishment)

ICE ([RFC 8445](https://www.rfc-editor.org/rfc/rfc8445.html)) is a framework that tries multiple connection methods and picks the one that works. The endpoint gathers a list of "candidates," which are addresses it might be reachable at: its local address, its STUN reflexive address, and a TURN relay address. It includes all of these candidates in the SDP offer. The remote end does the same. Both sides then perform connectivity checks on all candidate pairs and select the best one that actually works.

ICE is mandatory for browser-based calling but remains optional in SIP: both endpoints have to implement and enable it, which many desk phones and PBXes still don't. Where it is deployed, it's significantly more robust than STUN alone because it tests actual connectivity rather than making assumptions. Note that ICE establishes the *media* path; the SIP signaling itself still traverses NAT via its own mechanisms (rport, keep-alives, an outbound proxy or SBC).

### SIP ALG (Application Layer Gateway)

SIP ALG is a feature built into many routers that attempts to solve the NAT problem by inspecting SIP messages as they pass through the router and rewriting the embedded IP addresses. The router sees the Contact header with 10.0.0.50, knows that address was NATted to 203.0.113.1, and rewrites the Contact to use the public address. It does the same for the SDP body.

In theory, this is an elegant solution. The phone doesn't need to know or care about NAT. The router handles everything transparently.

In practice, SIP ALG is the source of an enormous number of VoIP problems. The implementations in consumer and small business routers are frequently buggy. Common issues include:

- Rewriting headers that shouldn't be rewritten
- Corrupting SDP bodies by changing IP addresses but not updating the Content-Length header
- Misclassifying non-SIP traffic on port 5060 and rewriting it (a transparent ALG cannot read SIP carried over TLS at all, which is why switching to TLS transport is a common way to route around a broken ALG)
- Interfering with phones that are already using STUN to handle NAT correctly, double-rewriting addresses into incorrect values
- Breaking registration by rewriting the Contact in REGISTER messages inconsistently

The almost universal advice from VoIP providers is to [disable SIP ALG](/blog/sip-alg-the-setting-that-breaks-everything) on your router. This advice is so widespread that it's essentially the first troubleshooting step for any SIP problem. If you're supporting VoIP and you haven't turned off SIP ALG, start there. Many call quality and connectivity problems simply disappear when ALG is disabled.

The difficulty is that different router manufacturers call this feature different things. It might be listed as "SIP ALG," "SIP Helper," "SIP Transformations," or buried in an "Application Layer Gateway" settings page. Some routers don't provide an obvious way to disable it. Some have it enabled by default with no option to turn it off without replacing the router.

### Session Border Controllers (SBCs)

SBCs are the professional solution. An SBC sits at the network edge and handles SIP and RTP by terminating the session on one side and re-originating it on the other. From the phone's perspective, it's communicating with the SBC. From the far end's perspective, it's communicating with the SBC. The SBC translates between the two, using its own public address in all the right places.

This completely eliminates the NAT problem because the phone only needs to reach the SBC, and the SBC uses publicly routable addresses when communicating with the outside world. SBCs are standard equipment in enterprise VoIP deployments and at SIP trunk providers. Most hosted PBX services use SBCs at their network edge, which is one of the reasons phones registered to cloud PBX platforms tend to have fewer NAT issues than phones connected to on premises PBX systems.

## NAT and registration

NAT affects registration in a subtle but important way. When a phone [registers](/blog/sip-registration) from behind NAT, the registrar records the Contact address from the SIP message, which contains the phone's private IP. When an inbound call arrives for that extension, the registrar directs the INVITE to the private address, which is unreachable from outside.

Smarter registrars handle this by looking at the "received" and "rport" parameters that get added to the Via header. These parameters record the actual source address that the registrar saw the REGISTER arrive from (the public NAT address), and the registrar can use that instead of the Contact address for routing inbound requests. This is sometimes called "NAT fix-up" or "force rport."

The other NAT registration problem is UDP timeout. NAT devices maintain their mapping tables for a limited time. If no traffic flows through a particular NAT mapping for a while (observed values run from 30 to 120 seconds for UDP, though anything under two minutes is a device that does not meet RFC 4787, which requires a UDP mapping to survive at least that long and recommends five minutes or more), the mapping expires and is removed. If the phone's re-registration interval is longer than the NAT timeout, the mapping will expire between registrations. The phone thinks it's registered, but the NAT mapping is gone, so inbound traffic can't reach it.

The standard workaround is to send periodic keep alive packets, often SIP OPTIONS messages or CRLF keep alives, at intervals shorter than the NAT device's UDP timeout. Most phones and PBX systems have a keep alive setting for exactly this purpose.

## Diagnosing NAT problems in a trace

When you're looking at a packet capture and you suspect a NAT issue, here's what to check:

1. Look at the SDP `c=` line in the INVITE and the 200 OK. If either one contains a private IP address (10.x.x.x, 172.16 through 172.31.x.x, 192.168.x.x) and the other party is on a different network, that's your problem.

2. Compare the source IP in the IP packet header with the Contact header in the SIP message. If they're different, the message passed through NAT and the SIP headers weren't corrected.

3. Check for audio flowing in only one direction by looking at the RTP streams. If you see RTP packets from one side but not the other, the missing side's RTP is likely being sent to an unreachable address.

4. Check whether SIP ALG is interfering by comparing the SDP before and after it passes through the router. If you capture on both sides of the NAT device and the SDP has been modified, ALG is active and may be causing the problem.

NAT traversal is messy, and the fact that it works as well as it does is a testament to the workarounds the industry has built. The transition that would make all of it unnecessary, [IPv6](/blog/ipv6-and-voip), has its own complications for voice. But when it doesn't work, the symptoms are consistent and identifiable once you know what to look for. A [PCAP analyzer](/tools/pcap-analyzer) can parse the SDP and headers from a capture to highlight exactly where the addressing mismatch is, and [SIP call stories](/tools/sip-call-stories) can walk you through the flow in plain language.

---

*Next up: [SIP Response Codes: A Practical Reference](/blog/sip-response-codes), covering the codes you'll actually encounter in troubleshooting and what they mean in practice.*

---

### Part 7: SIP Response Codes: A Practical Reference

URL: https://voiptest.com/blog/sip-response-codes
Published: 2026-04-13
Tags: sip, response-codes, voip, troubleshooting, reference

*SIP Signaling From the Wire Up: Part 7 of 12*

SIP response codes follow the same pattern as HTTP: a three digit number where the first digit tells you the general category and the specific number tells you what happened. If you've ever seen a 404 error on a website, you already have the intuition for how this works.

The full SIP specification defines dozens of response codes, but in real world VoIP troubleshooting, you'll encounter a relatively small subset of them repeatedly. This post focuses on those, the codes that actually show up when you're reading a trace and trying to figure out why a call failed, why registration broke, or why a transfer didn't go through. Think of it as a field reference rather than a comprehensive catalog.

## 1xx: Provisional Responses

Provisional responses are informational. They tell the sender that the request was received and is being processed, but the final outcome hasn't been determined yet.

### 100 Trying

The proxy or server received the request and is working on it. This is a hop by hop response, meaning each proxy in the chain sends its own 100 Trying back to the previous hop. Its main purpose is to stop retransmissions. When SIP runs over UDP, the sender will keep resending the request until it gets some kind of response. A 100 Trying says "I got it, stop resending."

If you're looking at a trace and you see the caller sending multiple identical INVITEs with no 100 Trying in between, the initial INVITE isn't reaching the first proxy, or the 100 Trying isn't making it back. That's usually a firewall or routing issue.

### 180 Ringing

The callee's phone is ringing. When the caller's phone receives this, it plays a ringback tone. In a normal call, you'll see 180 Ringing after 100 Trying and before 200 OK.

If you see the INVITE reach the callee's phone (you can verify by capturing at both ends) but no 180 comes back, the callee's phone received the INVITE but isn't generating a ringing response. This could be a configuration issue on the phone, or the phone could be rejecting the call silently.

### 183 Session Progress

This one is important and often misunderstood. A 183 response typically includes an SDP body and signals that "early media" is available. Early media is audio that plays before the call is fully answered. The most common use case is ringback tones generated by the far end network rather than by the caller's phone, or IVR prompts that play before the call is picked up by a human.

When a caller hears a recorded message like "Please hold while we transfer your call" before anyone has technically answered, that audio is early media signaled by a 183 response.

In the trace, a 183 with SDP means the caller should start sending and receiving RTP even though the call hasn't been answered yet. If you see a 183 but the caller isn't hearing the early media, check whether the caller's phone or proxy supports early media, and whether the RTP path is working (same NAT and firewall considerations as with established calls).

## 2xx: Success

### 200 OK

The request succeeded. The meaning depends on what was requested. A 200 OK to an INVITE means the call was answered. A 200 OK to a REGISTER means registration was accepted. A 200 OK to a BYE means the hangup was acknowledged. A 200 OK to a CANCEL means the cancellation was received.

In INVITE transactions, the 200 OK typically carries an SDP answer body. If you're troubleshooting a call that connects but has no audio, the SDP in the 200 OK is one of the first things to check.

## 3xx: Redirection

### 301 Moved Permanently

The address being called has permanently moved to a different address. The response includes a Contact header with the new address. The caller's system should update its records and send the INVITE to the new location. This is sometimes used to implement permanent call forwarding.

### 302 Moved Temporarily

Same concept as 301, but the move is temporary. The caller should try the new address for this call but shouldn't update permanent records. Used for temporary call forwarding and some load balancing implementations.

In practice, not all SIP devices handle 3xx redirects correctly. Some older phones or PBX systems ignore them entirely. If you see a 302 in a trace and the call isn't being forwarded as expected, check whether the device receiving the 302 supports redirect handling.

## 4xx: Client Errors

This is the category you'll spend the most time in when troubleshooting. A 4xx response means the request itself had a problem.

### 400 Bad Request

The request was malformed in some way that the server can't process it. This is a catch all for syntax errors, missing required headers, or other problems with the message structure. The Reason phrase or a Warning header might give more detail about what specifically was wrong. [SIP ALG](/blog/sip-nat-traversal) mangling messages can produce 400 errors because the rewritten message ends up structurally invalid.

### 401 Unauthorized

Authentication is required and wasn't provided, or the provided credentials were incorrect. This is the standard challenge response used in [SIP registration](/blog/sip-registration). The first REGISTER without credentials gets a 401 with a WWW-Authenticate header. The client should retry with credentials. If you see a 401, followed by an authenticated request, followed by another 401, the credentials are wrong. The phone will keep trying and keep failing, which you'll see as a repeating pattern in the trace.

### 403 Forbidden

The server understood the request and the credentials (if provided) but is refusing to fulfill it. This is different from 401. A 401 says "authenticate yourself." A 403 says "I know who you are, and the answer is no." Common causes include IP based access restrictions, calling permissions that don't allow the dialed number, or an administrative block on the account.

### 404 Not Found

The address in the Request-URI doesn't exist. Nobody is registered at that address, and the server doesn't know how to route to it. If you dial an extension that doesn't exist on the PBX, you'll get a 404. If a SIP trunk receives a call for a number that isn't configured in the routing table, you might get a 404.

### 407 Proxy Authentication Required

Identical in concept to 401, but it comes from a proxy rather than the endpoint server. The challenge header is Proxy-Authenticate instead of WWW-Authenticate, and the client should include a Proxy-Authorization header in the retry. Functionally, the troubleshooting approach is the same as for 401.

### 408 Request Timeout

The server couldn't produce a response within the expected time. In practice, you'll see 408 when the INVITE was forwarded to a phone that isn't responding. The proxy waited for a response, none came, and it timed out. Common when the callee's phone is offline but still appears registered (the registration hasn't expired yet), or when a firewall is blocking the forwarded INVITE.

A 408 is one of the more common codes you'll see in troubleshooting, and it almost always points to a reachability problem on the callee's side.

### 480 Temporarily Unavailable

The callee's endpoint is valid but not reachable right now. This is similar to 408 but implies the server has more information. Maybe the phone recently went offline, or the user has enabled a "do not disturb" setting that rejects calls without ringing.

### 486 Busy Here

The callee is busy. Their phone is already on a call and doesn't accept additional calls. This is the SIP equivalent of a busy signal.

### 487 Request Terminated

The request was cancelled. You'll see this when a caller hangs up while the phone is still ringing. The sequence is: INVITE, 180 Ringing, CANCEL, 200 OK (to the CANCEL), 487 Request Terminated (to the original INVITE), ACK (to the 487). This is normal behavior, not an error, despite being in the 4xx range.

### 488 Not Acceptable Here

The request was understood but the media parameters are unacceptable. In practice, this almost always means a codec mismatch. The INVITE offered codecs that the callee doesn't support. Check the [SDP](/blog/sdp-media-negotiation) in the INVITE against the callee's configured codecs.

### 491 Request Pending

Both sides tried to modify the session at the same time (both sent re-INVITEs simultaneously). The side that receives a 491 should wait a random interval and retry. This is usually handled automatically and you rarely need to troubleshoot it, but seeing a lot of 491s might indicate a timing issue with hold/transfer operations.

## 5xx: Server Errors

### 500 Internal Server Error

Something went wrong on the server. This is the server saying "I tried to process your request but I failed, and it's my fault, not yours." Check the server's logs for more detail.

### 502 Bad Gateway

The server, acting as a proxy, received an invalid response from the next hop. This can indicate a problem with an intermediate proxy or SBC, or a misconfigured routing table that's sending calls to a nonexistent destination.

### 503 Service Unavailable

The server can't handle the request right now, usually because it's overloaded or undergoing maintenance. For [SIP trunks](/blog/sip-trunking), a 503 from the carrier might indicate trunk capacity has been reached or there's an outage on their side. It shows up often enough in trunk troubleshooting that [503 has its own deep dive](/blog/sip-503-service-unavailable).

## 6xx: Global Failures

### 600 Busy Everywhere

The callee was contacted at multiple locations (maybe they have a desk phone and a softphone) and all of them are busy. This is like 486 but applies to all registered endpoints for the user.

### 603 Decline

The callee explicitly rejected the call. The call was offered and deliberately refused, as opposed to being unanswered or unavailable. Some implementations use 603 when a user presses the "reject" button on an incoming call.

## Using response codes in troubleshooting

When you're working through a SIP trace, response codes are your primary indicators of what happened and where. It helps to know [what a healthy call flow looks like](/blog/first-call-flow-invite-to-bye) first, so you can spot which response never arrived. The troubleshooting approach is:

Find the failed transaction by looking for the non-2xx final response. [Look up the response code](/tools/sip-codes) and understand what category of problem it represents. Then look at the context: what was the request? Where did the response come from? What were the headers in both the request and the response?

A 488 coming back from a carrier's SBC tells you the codec negotiation failed with the carrier. A 408 from your proxy tells you the callee's phone didn't respond. A 403 from the registrar tells you the account is blocked. The response code narrows your search from "something is broken" to a specific area of investigation.

---

*Next up: [Authentication and Security in SIP](/blog/sip-authentication-security), covering how SIP handles credentials, what encryption options exist, and why toll fraud is a real threat.*

---

### Part 8: Authentication and Security in SIP

URL: https://voiptest.com/blog/sip-authentication-security
Published: 2026-04-14
Tags: sip, security, authentication, toll-fraud, srtp, tls

*SIP Signaling From the Wire Up: Part 8 of 12*

SIP was designed in an era when the internet was a more trusting place. The protocol's authentication mechanisms are functional but not particularly strong by modern standards, and its default mode of operation sends everything in plain text. This isn't a secret or a flaw that nobody has noticed. It's a known characteristic of the protocol that the industry has addressed through a combination of transport layer security, application level protections, and operational practices.

Understanding how SIP handles authentication and what the security landscape looks like puts you in a position to evaluate the security posture of your own VoIP deployment and to understand why certain security recommendations exist.

## Digest authentication

The most common authentication mechanism in SIP is digest authentication, which we saw briefly in the [registration post](/blog/sip-registration). Let's look at it more closely.

Digest authentication is a challenge/response mechanism. The server challenges the client to prove it knows a shared secret (the password) without transmitting the password itself. Here's the complete flow with the relevant headers.

The client sends a request (a REGISTER, an INVITE, or any other method the server requires authentication for):

```
REGISTER sip:example.com SIP/2.0
...
```

The server rejects it with a 401 Unauthorized and includes a challenge:

```
SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest realm="example.com",
  nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
  qop="auth",
  algorithm=MD5,
  opaque="5ccc069c403ebaf9f0171e9517f40e41"
```

The key fields in the challenge are:

**realm** is the authentication domain. This is typically the SIP domain and is included in the hash calculation.

**nonce** is a server-generated value that the client must fold into its hash. Contrary to a common simplification, the nonce is not necessarily single-use: RFC 3261 leaves nonce lifetime policy to the server, and many servers accept the same nonce for a window of time or a number of requests, signalling an expired one with `stale=true` so the client can retry without re-prompting for the password. Replay protection comes from the nonce *in combination with* the qop machinery below, not from the nonce alone.

**qop** stands for quality of protection. When set to "auth," it means the server wants authentication and obligates the client to supply a nonce count (`nc`) and client nonce (`cnonce`). Because `nc` increments on every reuse of a nonce, the server can detect a replayed request even under a still-valid nonce; this is where the real replay protection lives. When qop is "auth-int," the server also wants integrity protection of the message body.

**algorithm** specifies the hash algorithm to use. MD5 remains the most widely deployed but should be treated as legacy. RFC 8760 defines SHA-256 and SHA-512/256 for SIP digest; where both your server and endpoints support it, prefer a SHA-256-capable configuration.

The client computes the digest response by combining the username, password, realm, nonce, method, and URI using the specified algorithm, then sends the request again with an Authorization header:

```
REGISTER sip:example.com SIP/2.0
Authorization: Digest username="alice",
  realm="example.com",
  nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
  uri="sip:example.com",
  response="6629fae49393a05397450978507c4ef1",
  algorithm=MD5,
  qop=auth,
  nc=00000001,
  cnonce="0a4f113b",
  opaque="5ccc069c403ebaf9f0171e9517f40e41"
```

The `response` field is the computed hash. The `nc` (nonce count) increments with each use of the same nonce, preventing replay within a nonce's lifetime. The `cnonce` (client nonce) is a value generated by the client that adds additional randomness to the hash calculation.

The server performs the same computation using the password it has stored for alice. If the computed hash matches the `response` value in the Authorization header, the client has proven it knows the password.

## The weakness of digest authentication

Digest authentication is better than sending a password in plain text, but it has known weaknesses.

The most significant is that most deployments still run it over MD5, which is considered cryptographically weak and is best treated as a legacy algorithm now that RFC 8760 has standardized SHA-256 for SIP digest. While it's not trivial to reverse an MD5 hash to recover the original password, it is feasible to brute force short or common passwords by computing the hash for every candidate password and comparing against the captured response. Tools exist specifically for cracking SIP digest hashes from captured REGISTER or INVITE messages.

This means that if someone can capture your SIP traffic (which is straightforward on a shared network since SIP typically runs unencrypted over UDP), they can extract the digest challenge and response, and then attempt to crack the password offline. Short passwords, dictionary words, and predictable patterns are especially vulnerable.

The practical takeaway is that SIP credentials should be long, random, and unique. Treat them like any other system password. The digest mechanism provides a thin layer of protection, but it's not something to rely on against a determined attacker.

## Transport security: UDP, TCP, and TLS

By default, SIP messages travel in plain text over UDP. Anyone who can capture network traffic on the path between your phone and the server can read every SIP message, including the INVITE headers that reveal who's calling whom, and the SDP bodies that reveal the IP addresses and ports where audio will flow.

SIP supports three transport protocols:

**UDP** is the most common. It's connectionless, lightweight, and fast. The downside is no encryption, no delivery guarantee (SIP handles retransmissions itself), and a practical size limitation: RFC 3261 specifies that SIP messages larger than 1300 bytes should be sent over TCP instead of UDP to proactively avoid IP fragmentation. (The actual IP fragmentation point on standard Ethernet is around 1472 bytes of UDP payload, but the RFC sets a lower threshold to provide a safety margin across varying path MTUs.)

**TCP** provides reliable, ordered delivery. It solves the fragmentation problem and is sometimes required for large SIP messages. But like UDP, TCP SIP is unencrypted.

**TLS** (Transport Layer Security) encrypts the SIP messages in transit. When SIP runs over TLS, it's sometimes referred to as SIPS (though the terminology is used inconsistently). TLS protects the signaling from eavesdropping and tampering between the phone and the next hop. A connection secured with TLS looks like this in SIP:

```
Via: SIP/2.0/TLS 10.0.0.50:5061;branch=z9hG4bK74bf9
```

Note the transport is TLS and the port is 5061, which is the standard port for SIP over TLS (versus 5060 for unencrypted SIP).

Important caveat: TLS encrypts the signaling only. It protects the SIP INVITE, the SDP, the headers, and the registration credentials from being read in transit. It does not encrypt the audio. For audio encryption, you need SRTP.

Also, TLS is typically hop by hop. If your phone connects to your PBX over TLS, but your PBX connects to the SIP trunk provider over UDP, the signaling is encrypted on the first leg and unencrypted on the second. End to end encryption of signaling requires TLS on every hop, which is often not the case in practice.

## SRTP: encrypting the audio

SRTP (Secure Real-time Transport Protocol) is the encrypted version of RTP. When SRTP is negotiated in the [SDP](/blog/sdp-media-negotiation), the audio stream between the two endpoints is encrypted, protecting the voice conversation from eavesdropping.

SRTP negotiation appears in SDP as a change to the media line:

```
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
  inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj
```

The `RTP/SAVP` profile (instead of `RTP/AVP`) indicates SRTP. The `a=crypto` attribute contains the encryption suite and the key material.

Some implementations use DTLS-SRTP instead, where the encryption keys are negotiated through a DTLS handshake rather than being included in the SDP. This approach is used by browser-based calling and is generally considered more secure because the key material isn't transmitted in a signaling message that might pass through intermediaries.

The practical state of SRTP adoption varies. Most hosted PBX providers support it. Many on premises PBX systems support it. But in a lot of deployments, it's not enabled by default, and the administrator has to specifically turn it on. If you're evaluating the security of a VoIP deployment, check whether SRTP is configured, not just available.

## SIP toll fraud

Toll fraud is probably the most tangible security threat to SIP systems, and it's one that costs real money. The basic scenario is: an attacker gains access to your SIP system and uses it to make expensive international or premium rate calls. The calls are billed to your account. You discover the problem when you get a phone bill for thousands of dollars.

The most common attack vector is brute forcing registration credentials. The attacker scans the internet for SIP devices listening on port 5060 (which is easy to find because SIP registration traffic is constant and predictable). Once they find a SIP server or PBX, they try registering with common usernames and passwords. Extensions like "100," "200," or "admin" with passwords like "1234," "password," or the same string as the extension are shockingly common and are the first things attackers try.

What a brute force attempt looks like in a trace is a rapid series of REGISTER messages with different credentials, each one getting a [401 challenge or 403 rejection](/tools/sip-codes). Automated tools can try thousands of combinations quickly.

Once the attacker successfully registers, they send INVITEs to international premium rate numbers (often in regions where the attacker has arranged to receive a per minute payment from the terminating carrier). The calls look legitimate to your SIP trunk provider because they're coming from an authenticated registration on your system. The charges accumulate rapidly, sometimes reaching tens of thousands of dollars over a weekend.

### Protecting against toll fraud

**Strong, random passwords.** Every extension should have a unique, random password of at least 12 characters. Never use the extension number as the password. Never use dictionary words.

**Rate limiting and fail2ban.** Configure your PBX to detect and block IP addresses that are generating a high volume of failed authentication attempts. Tools like fail2ban can monitor SIP logs and automatically firewall offending IPs. Asterisk, FreeSWITCH, and most modern PBX platforms support this either natively or through add-ons.

**Geographic call restrictions.** If your business doesn't need to call international numbers, block them on your SIP trunk. Most trunk providers allow you to set geographic restrictions on outbound dialing. If you only call domestic numbers, there's no reason to leave international dialing enabled.

**Restrict registration by IP.** If your phones are on known IP addresses or subnets, configure your PBX to only accept registrations from those addresses. This is simple and effective.

**Monitor your call records.** Set up alerts for unusual call patterns: a spike in international calls, calls outside business hours, calls to premium rate numbers, or a single extension placing an unusual volume of calls. Early detection limits the financial damage.

**Use TLS for registration.** Encrypted registration prevents attackers from capturing and cracking credentials off the wire. It doesn't prevent brute force attacks (the attacker can still try credentials against the TLS port), but it eliminates one attack vector.

## The security reality

Most SIP deployments in the real world are not fully secured. Internal traffic runs over UDP without encryption. Digest authentication with MD5 is the norm. SRTP is available but often not enabled. [SIP ALG](/blog/sip-nat-traversal) on the router is mangling packets in ways that complicate security analysis.

This is not ideal, but it's the reality that most VoIP systems operate in. The practical approach is to prioritize the protections that address the most likely threats: strong credentials to prevent toll fraud, fail2ban to block brute force attempts, geographic restrictions to limit the damage of a compromise, and TLS on externally facing connections to protect signaling from eavesdropping on untrusted networks. Full end to end encryption of both signaling and media is achievable but requires deliberate configuration across every component in the path.

---

*Next up: [Call Features in SIP: Hold, Transfer, and Forwarding](/blog/sip-call-features), where we look at how the buttons on your phone translate into SIP messages on the wire.*

---

### Part 9: Call Features in SIP: Hold, Transfer, and Forwarding

URL: https://voiptest.com/blog/sip-call-features
Published: 2026-04-15
Tags: sip, hold, transfer, refer, call-features, voip

*SIP Signaling From the Wire Up: Part 9 of 12*

Every phone has a hold button, a transfer button, and some kind of forwarding capability. These features feel simple when you're pressing buttons on a handset, but the SIP signaling that makes them work is more complex than the basic call setup we covered in earlier posts. This complexity is also where a lot of interoperability problems live. A transfer that works perfectly between two phones from the same manufacturer might fail when one side is a different brand, or when the call passes through certain PBX platforms or SBCs.

Understanding how these features work at the protocol level helps you diagnose why a hold is producing silence instead of music, why a transfer is dropping the call, or why [forwarding isn't behaving as expected](/blog/calls-going-to-voicemail).

## Hold

When you press the hold button on your phone, the phone needs to tell the other end to stop sending audio (or to expect that it will stop receiving audio, depending on the implementation). SIP handles this through a re-INVITE that modifies the media session.

Here's what happens. Alice and Bob are on an active call. The SDP on both sides has `a=sendrecv`, meaning both are sending and receiving audio. Alice presses hold. Her phone sends a re-INVITE with a modified [SDP](/blog/sdp-media-negotiation):

```
INVITE sip:bob@192.168.1.100:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK8823
...
Call-ID: 3848276298220188511@10.0.0.50
CSeq: 2 INVITE
Content-Type: application/sdp
Content-Length: 198

v=0
o=alice 2890844526 2890844527 IN IP4 10.0.0.50
s=Call
c=IN IP4 10.0.0.50
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
```

The critical change is the last line: `a=sendonly` instead of `a=sendrecv`. This tells Bob's phone that Alice will still send audio (hold music, potentially) but will not be receiving audio. Bob's phone should stop sending its audio to Alice.

Notice that the session version in the `o=` line incremented from `2890844526` to `2890844527`. This tells Bob's phone that the SDP has changed and the new parameters should be applied.

Bob's phone responds with a 200 OK and its own SDP, acknowledging the hold:

```
SIP/2.0 200 OK
...
Content-Type: application/sdp

v=0
o=bob 2808844564 2808844565 IN IP4 192.168.1.100
s=Call
c=IN IP4 192.168.1.100
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=recvonly
```

Bob's response says `a=recvonly`, which is the correct complement to Alice's `sendonly`. Bob will receive (Alice's hold music) but won't send.

When Alice takes the call off hold, she sends another re-INVITE with `a=sendrecv`, and the call returns to its normal two way state.

### Hold variations

Not all implementations handle hold the same way. Some phones use `a=inactive` instead of `a=sendonly`, which produces complete silence in both directions. Some phones change the media destination in the `c=` line to 0.0.0.0, which is an older method of signaling hold that predates the direction attributes. Some phones do both. If you're troubleshooting a hold that isn't behaving as expected, check the SDP in the re-INVITE to see which method the phone is using.

The hold music question is also relevant. If Alice's phone sends `a=sendonly` and plays hold music, Bob hears the music because Alice is still sending. But the hold music might be generated by Alice's phone locally, or it might be generated by the PBX. If the PBX is supposed to provide hold music, the phone might need to signal hold differently, sometimes by sending the re-INVITE to the PBX rather than directly to Bob, so the PBX can insert itself into the media path. This varies by PBX platform.

## Attended transfer

Attended transfer (sometimes called consultative transfer) is when Alice is on a call with Bob, puts Bob on hold, calls Charlie to make sure Charlie is available, and then connects Bob to Charlie while Alice drops out.

The SIP signaling for this involves the REFER method (RFC 3515). In this example the REFER travels inside the existing Alice–Bob dialog, which is the common case for transfers, but RFC 3515 doesn't require that: a REFER may also be sent outside any existing dialog, creating its own dialog through the implicit subscription it establishes (out-of-dialog REFER is how some click-to-dial and call-pickup features work). Here's the sequence:

1. Alice is on a call with Bob (Call A)
2. Alice puts Bob on hold (re-INVITE with sendonly, as described above)
3. Alice calls Charlie (Call B, a completely separate SIP dialog with its own INVITE, 200 OK, ACK)
4. Alice talks to Charlie and confirms the transfer
5. Alice sends a REFER to Bob, telling him to establish a new call with Charlie:

```
REFER sip:bob@192.168.1.100:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK9921
...
Call-ID: 3848276298220188511@10.0.0.50
CSeq: 4 REFER
Refer-To: <sip:charlie@192.168.1.200?Replaces=callid%40host
  %3Bto-tag%3Dxyz%3Bfrom-tag%3Dabc>
Referred-By: <sip:alice@example.com>
```

The Refer-To header is the important one. It tells Bob's phone the address to connect to, and the Replaces parameter tells Charlie's phone which existing call to replace (Call B between Alice and Charlie). This allows Bob to seamlessly take over Alice's conversation with Charlie.

6. Bob's phone acknowledges the REFER with a 202 Accepted
7. Bob's phone sends an INVITE to Charlie with a Replaces header
8. Charlie's phone accepts, replacing Call B with a new call to Bob
9. Bob's phone sends NOTIFY messages back to Alice, reporting the progress:

```
NOTIFY sip:alice@10.0.0.50:5060 SIP/2.0
...
Event: refer
Content-Type: message/sipfrag

SIP/2.0 200 OK
```

This NOTIFY tells Alice that the transfer succeeded (Bob got a 200 OK from Charlie). Alice can now tear down both of her original call legs.

### Why transfers fail

Attended transfers are one of the most complex operations in SIP, and they're a common source of interoperability problems. Common failure points include:

**REFER not supported.** Some older devices or stripped down SIP implementations don't support the REFER method. They'll respond with a [405 Method Not Allowed](/blog/sip-response-codes).

**Replaces header not supported.** The Replaces mechanism is defined in a separate RFC (RFC 3891) and not all implementations handle it correctly. Without Replaces working properly, the transfer can't seamlessly take over the existing call leg, resulting in dropped audio or a second ringing phase that the transferred party doesn't expect.

**Firewall blocking the new INVITE.** The REFER tells Bob to send an INVITE to Charlie. If there's a firewall between Bob and Charlie that wasn't in the path of the original calls (which both went through Alice), the new INVITE might be blocked.

**SBC complications.** Session Border Controllers that are managing the signaling may not properly handle the REFER or may not relay the Replaces header correctly.

## Blind transfer

Blind transfer (sometimes called unattended transfer) is simpler. Alice sends a REFER to Bob with Charlie's address, but Alice hasn't called Charlie first. Bob's phone sends an INVITE to Charlie. If Charlie answers, the transfer succeeds. If Charlie doesn't answer, the behavior depends on the implementation. Some phones reconnect Bob to Alice. Others drop the call entirely.

The REFER message looks similar to attended transfer but without the Replaces parameter:

```
REFER sip:bob@192.168.1.100:5060 SIP/2.0
...
Refer-To: <sip:charlie@example.com>
Referred-By: <sip:alice@example.com>
```

Blind transfer is less complex but has its own failure modes, particularly the "what happens when nobody answers" problem. Different phone platforms handle this differently, which is why blind transfers can behave inconsistently across mixed environments.

Transfer is the most involved of the call features and the one that breaks first in mixed-vendor environments. For the full message flow, the NOTIFY progress chain, how SBCs change what you see on the wire, and a fault-by-fault diagnostic table, see [How Call Transfer Works in SIP](/blog/sip-call-transfer-explained).

## Call forwarding

Call forwarding can be implemented in several ways in SIP, and the method used determines what the caller sees and experiences.

### Server side forwarding (retargeting)

The most common approach is for the server (PBX or proxy) to handle forwarding internally. When a call arrives for Bob and Bob has forwarding enabled, the server simply redirects the INVITE to the forwarding destination without telling the caller. The caller's phone shows that it's calling Bob. Bob's phone never rings. The forwarding target answers, and the caller may not even know the call was forwarded.

In the trace, you'd see the INVITE arrive at the server for Bob, and then the server generating a new INVITE to the forwarding destination. The caller only sees normal call setup.

### Redirect response (302)

The server can respond to the INVITE with a 302 Moved Temporarily, including the forwarding address in the Contact header:

```
SIP/2.0 302 Moved Temporarily
...
Contact: <sip:charlie@example.com>
```

This tells the caller's system to try the new address. The caller's phone or proxy then sends a new INVITE to Charlie. The caller might see a brief change on their display as the call is retargeted.

The advantage of 302 is that the server doesn't have to stay in the media path. The disadvantage is that not all caller devices handle 302 responses correctly, and some PBX platforms generate them in ways that confuse the receiving end.

### Recording the forward: Diversion and History-Info

When a call has been forwarded, a header can record that fact. The one you'll most often see in the wild is Diversion:

```
Diversion: <sip:bob@example.com>;reason=unconditional
```

This header is added to the INVITE by the forwarding server and tells the destination (and any intermediary) that this call was originally for Bob and was forwarded. The `reason` parameter indicates why: unconditional (always forward), no-answer (Bob didn't pick up), busy (Bob is on another call), or unavailable (Bob is offline).

It's worth knowing Diversion's status: it's a widely deployed historical header (documented for the record in RFC 5806, which is classified Historic), not the IETF standards-track mechanism. The standards-track answer is History-Info (RFC 7044), which records the entire retargeting chain (every URI the request was aimed at, in order, with reason and privacy parameters) rather than just the last diverting party. Carrier interconnects and voicemail platforms increasingly expect History-Info, and gateways commonly translate between the two.

Not all systems populate or read either header, but when one is present, it's useful for understanding call routing history, and when both are present, check that they agree.

## Conference calls

SIP doesn't have a native conferencing mechanism. Three way calls and conference bridges are typically handled by the PBX or a dedicated media server that mixes the audio from multiple participants.

The SIP signaling for a conference usually involves the PBX creating multiple call legs, one to each participant, and mixing the audio from all legs together. Some implementations use REFER to move participants onto a conference bridge. Others have the PBX internally create the conference and bridge the existing call legs into it.

Because conferencing is implemented at the application level rather than in the protocol itself, the behavior varies significantly between PBX platforms. The underlying SIP is just normal call setup on each leg. The conferencing magic happens in the audio mixing, which is an RTP function, not a SIP function. If you are designing call flows that combine auto attendants, transfers, queues, and conferencing, an [IVR planner](/tools/ivr-planner) can help you map the routing visually before you start configuring the PBX.

---

*Next up: [SIP Trunking: Connecting to the Outside World](/blog/sip-trunking). We cover how your phone system connects to the public telephone network through SIP.*

---

### Part 10: SIP Trunking: Connecting to the Outside World

URL: https://voiptest.com/blog/sip-trunking
Published: 2026-04-16
Tags: sip, sip-trunking, pstn, voip, did, itsp

*SIP Signaling From the Wire Up: Part 10 of 12*

Everything we've covered so far has been about SIP communication between endpoints on a network, phones talking to PBX systems, phones talking to each other through proxies. But most businesses also need to make and receive calls to and from the public telephone network: landlines, mobile phones, and anyone who isn't on your SIP system. That connection between your SIP infrastructure and the public phone network is a SIP trunk.

SIP trunking replaced the older model of connecting to the phone network through physical circuits like PRI (Primary Rate Interface) lines, which used dedicated T1 or E1 circuits with ISDN signaling. A PRI gave you a fixed number of channels (typically 23 voice channels on a T1) over a dedicated physical connection. SIP trunking provides the same connectivity, calls to and from the public phone network, but over your existing internet connection using SIP signaling. This is the shift that made [physical phone lines obsolete](/blog/voip-lines-dont-exist): capacity became a contract term rather than a count of copper pairs.

## How a SIP trunk works

A SIP trunk is a logical connection between your PBX and an Internet Telephony Service Provider (ITSP), which is the company that bridges SIP traffic to the public switched telephone network (PSTN). The ITSP operates gateway equipment that converts between SIP/RTP on the internet side and the traditional telephone network signaling (SS7, ISDN) on the PSTN side.

When someone in your office dials an outside number, the call flows like this:

1. The desk phone sends a SIP INVITE to your PBX
2. Your PBX determines this is an outbound call (not an internal extension) and routes it to the SIP trunk
3. The PBX sends a SIP INVITE to the ITSP's SBC with the dialed number
4. The ITSP's equipment converts the SIP signaling to PSTN signaling and connects the call into the telephone network
5. The call reaches the destination phone through the traditional phone network

Inbound calls follow the reverse path. Someone dials your business phone number. The call arrives at the ITSP through the PSTN. The ITSP converts it to a SIP INVITE and sends it to your PBX. Your PBX routes it to the appropriate extension.

## Trunk authentication models

SIP trunks use one of two authentication approaches, and understanding which one your trunk uses matters for both configuration and troubleshooting.

### IP based authentication

With IP authentication, the ITSP configures their SBC to accept traffic from your PBX's public IP address. No SIP registration is needed. Your PBX simply sends INVITEs to the ITSP's SBC address, and the ITSP accepts them because the source IP matches their configuration.

An outbound call over an IP authenticated trunk looks like this:

```
INVITE sip:+15551234567@sbc.provider.com SIP/2.0
Via: SIP/2.0/UDP 203.0.113.1:5060;branch=z9hG4bK4432
Max-Forwards: 70
To: <sip:+15551234567@sbc.provider.com>
From: "Main Office" <sip:+15559876543@example.com>;tag=as2e0398f
Call-ID: 42f7a8c9e0df@203.0.113.1
CSeq: 102 INVITE
Contact: <sip:203.0.113.1:5060>
Content-Type: application/sdp
Content-Length: 245

[SDP body]
```

Notice the Request-URI contains the dialed number in E.164 format (the international numbering standard, with a + prefix and country code). The From header contains the caller's phone number, but be careful about what that header actually is: From is user-supplied dialog identity, not a trusted network assertion. In trusted SIP networks, the authenticated identity commonly travels in a P-Asserted-Identity header (RFC 3325), with a Privacy header controlling whether it may be presented; and whether the ITSP derives outbound [caller ID](/blog/caller-id-problems) from P-Asserted-Identity, from From, or from your account configuration is provider policy. The Contact header shows the PBX's public IP address.

The ITSP's SBC sees the INVITE arriving from 203.0.113.1, checks that this IP is authorized, and processes the call. No 401 challenge is needed.

IP authentication is simple and common for on premises PBX deployments with static public IP addresses. The main requirement is that your PBX has a consistent public IP, which means either a static IP from your ISP or a consistent NAT mapping. If your public IP changes (common with residential grade internet connections), the ITSP's configuration will be wrong and your calls will fail until the IP is updated.

### Registration based authentication

With registration authentication, your PBX registers with the ITSP just like a phone registers with a PBX. The PBX sends a REGISTER to the ITSP's SBC, goes through the digest authentication challenge, and maintains an active registration. Calls are then sent within the context of that registration.

```
REGISTER sip:provider.com SIP/2.0
Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bK771
Max-Forwards: 70
To: <sip:mytrunk@provider.com>
From: <sip:mytrunk@provider.com>;tag=reg38
Call-ID: reg88721@10.0.0.1
CSeq: 1 REGISTER
Contact: <sip:10.0.0.1:5060>
Expires: 3600
Content-Length: 0
```

Registration authentication is more flexible because it works regardless of the PBX's public IP. The ITSP identifies the trunk by the registration credentials, not the source IP. This makes it suitable for PBX systems behind dynamic IPs, and it's the more common model for cloud hosted PBX platforms.

The tradeoff is that the registration needs to be maintained. If registration fails or expires, the trunk goes down. All the registration troubleshooting concepts from [post 4](/blog/sip-registration) apply here: credential errors, firewall issues, NAT timeouts, and DNS failures can all prevent the trunk from registering or staying registered.

## Codec negotiation on trunks

When a call crosses a SIP trunk, codec negotiation happens between your PBX and the ITSP's SBC, independently of whatever codec is being used on the internal leg between the phone and the PBX.

Most ITSPs support G.711 (both PCMU and PCMA) as a baseline because G.711 is the standard encoding of the PSTN. When a call enters or exits the traditional phone network, it's G.711. If your trunk is also using G.711, there's no transcoding needed at the ITSP's gateway, which is ideal for quality.

Many ITSPs also support G.729, which uses significantly less bandwidth than G.711 (about 8 kbps versus 64 kbps of codec payload per call, before packet overhead). If bandwidth is limited, G.729 on the trunk can be a reasonable tradeoff. But G.729 is a lossy compression codec, and how many lossy cycles the audio goes through depends on what happens between the legs, not simply on both legs using it. Each leg negotiates its codec independently through SDP offer/answer (RFC 3264), and if the internal leg and the trunk leg agree on the same codec and packetization, a PBX that can pass the media through performs no transcoding: the audio is encoded once at the phone and decoded once at the far side. Double lossy encoding occurs only when the media is actually decoded and re-encoded along the way: mismatched codecs on the two legs, or a PBX function such as recording, conferencing, or DTMF interworking that forces it into the media path as a transcoder. That decode/re-encode cycle is what compounds quality degradation, so it's worth confirming whether your PBX passes G.729 through or transcodes it.

Some modern ITSPs support Opus on their trunks, which can provide better quality than G.711 at comparable or lower bitrates. Support for Opus on SIP trunks is growing but not yet universal.

The codec negotiation appears in the SDP, as covered in [post 5](/blog/sdp-media-negotiation). If you're troubleshooting a [488 Not Acceptable Here](/blog/sip-response-codes) on an outbound call, the codec lists in your PBX's INVITE and the ITSP's supported codecs don't overlap.

## Trunk capacity

A PRI gave you a fixed number of channels, typically 23 on a T1. You could make or receive exactly 23 simultaneous calls, no more. SIP trunks are more flexible, but capacity is still a consideration.

Some ITSPs sell trunk capacity as a fixed number of concurrent channels, similar to a PRI. You buy 10 channels, you can make 10 simultaneous calls. Others sell unlimited concurrent calls and rely on your internet bandwidth being the practical limit. Still others dynamically adjust capacity based on your subscription level. Keep in mind what a purchased channel actually is: a contractual concurrency entitlement, not a reserved piece of hardware. Whether the provider statistically multiplexes the underlying call-processing, media and interconnect resources, and what blocking or performance commitment applies when demand peaks, depends on the service design and on what you signed. That varies by provider and product rather than following a single industry practice, and it is not something you can read off a price list. Ask for the committed concurrent-session limit, what happens to calls above it, whether capacity is monitored, and what the SLA remedies. See [trunk capacity and what you can verify](/blog/voip-overbooking) for the longer version.

From a SIP perspective, there's no inherent limit. Each call is an independent INVITE transaction. The limits come from three places: the ITSP's policy (how many concurrent calls they allow for your account), your PBX's capacity (how many calls it can process simultaneously), and your internet bandwidth (how many RTP streams your connection can carry).

If you exceed your trunk's channel limit, additional outbound INVITEs will typically be rejected with a 503 Service Unavailable or a 486 Busy. Inbound calls that exceed capacity may get a busy signal or go to a voicemail server if one is configured. A [bandwidth calculator](/tools/bandwidth-calculator) can help you estimate how many concurrent calls your connection can support based on codec and overhead.

## Phone number management

SIP trunks carry your business phone numbers. These numbers, called DIDs (Direct Inward Dialing numbers), are assigned to your account by the ITSP and mapped to your SIP trunk. When someone dials one of your DIDs, the call arrives at the ITSP, which sends a SIP INVITE to your PBX with the dialed DID in the Request-URI.

Your PBX then uses the dialed DID to determine where to route the call internally. A call to your main number might go to an auto attendant. A call to a direct line might go straight to a specific extension. The DID in the incoming INVITE is what makes this routing possible.

When an INVITE arrives from the ITSP for an inbound call, it typically looks something like this:

```
INVITE sip:+15559876543@203.0.113.1:5060 SIP/2.0
Via: SIP/2.0/TLS sbc.provider.com:5061;branch=z9hG4bK88a3
...
To: <sip:+15559876543@203.0.113.1>
From: "John Doe" <sip:+15551234567@provider.com>;tag=prov334
...
```

The Request-URI and To header contain the DID that was dialed (+15559876543). The From header contains the calling party's number (+15551234567). Your PBX reads the DID from the Request-URI, matches it against its inbound routing rules, and sends the call to the right destination.

## Number porting

When a business switches to a new ITSP or moves to a SIP trunk from a traditional phone line, they usually want to keep their existing phone numbers. [Number porting](/blog/porting-numbers-office-move) is the process of transferring number ownership from one carrier to another.

At the SIP level, porting doesn't change anything. Once the numbers are ported to the new ITSP, inbound calls arrive as SIP INVITEs just like before. The porting process itself is a carrier level administrative process that typically takes one to four weeks, during which nothing changes on the technical side. On the cutover date, the numbers switch to the new carrier, and calls start arriving on the new trunk.

The risks during porting are mostly operational. If the porting process is delayed or has errors, calls to the ported numbers may fail during the transition. Having both the old and new service active during the porting window provides a safety net.

## SIP trunking versus hosted PBX

It's worth clarifying the distinction between SIP trunking and a hosted PBX, because the terms are sometimes used interchangeably even though they describe different architectures.

With SIP trunking, you operate a PBX (either a physical server in your office or a virtual machine) that handles all call routing, voicemail, auto attendant, and extension management. The SIP trunk provides only the connection to the outside world. You manage the PBX. The ITSP manages the trunk.

With a hosted PBX (also called cloud PBX or UCaaS), the PBX itself is run by the provider. Your phones register directly to the provider's servers, and the provider handles everything: internal call routing, voicemail, trunking to the PSTN, and all the features. You don't have a PBX to manage.

The SIP signaling is similar in both cases. Phones still send INVITEs, still register, still negotiate codecs through SDP. The difference is who manages the infrastructure and where the intelligence lives. From a troubleshooting perspective, the main impact is that with SIP trunking you have access to the PBX logs and can see both sides of the trunk. With a hosted PBX, you can see the phone side but the server side is in the provider's cloud, and you depend on their support team for visibility into that part of the path.

---

*Next up: [Reading a SIP Trace: Practical Troubleshooting](/blog/reading-a-sip-trace). Time to get hands on with the tools you'll use to capture and analyze SIP traffic.*

---

### Part 11: Reading a SIP Trace: Practical Troubleshooting

URL: https://voiptest.com/blog/reading-a-sip-trace
Published: 2026-04-17
Tags: sip, wireshark, sngrep, packet-capture, troubleshooting, voip

*SIP Signaling From the Wire Up: Part 11 of 12*

Everything in this series has been building toward this: the ability to capture SIP traffic, find the call you're interested in, and follow it through the signaling to figure out where things went wrong. This is the post where we get hands on with real tools and walk through real traces.

The good news is that SIP's text based design makes it far more readable than most network protocols. You don't need expensive proprietary analyzers. The tools we'll cover here are either free or built into the systems you're already using.

## Wireshark

Wireshark is the general purpose packet capture tool that every network technician should have in their toolkit. It captures all network traffic on an interface and provides powerful filtering and analysis capabilities. For SIP specifically, Wireshark has built in features that make call analysis significantly easier.

### Capturing SIP traffic

To capture SIP traffic, you need to run Wireshark on a machine that can see the SIP packets. This could be the PBX itself, a mirror port on a switch, or any machine on the network path between the endpoints you're interested in.

The simplest capture filter to isolate SIP is by port:

```
udp port 5060
```

This captures all UDP traffic on port 5060. Treat these port numbers as examples rather than a rule: 5060 (and 5061 for TLS) are the conventional defaults registered by RFC 3261, but the port a deployment actually uses comes from configuration, DNS SRV records, and provider policy; many providers deliberately run SIP on non-standard ports to dodge scanners and broken ALGs. Check what your deployment actually uses and adjust the filter accordingly. If you're using TLS, you'd capture with `tcp port 5061` (or whatever port is configured), though the encrypted payload won't be readable without the decryption keys.

If you don't apply a capture filter, Wireshark captures everything, and you'll need to use a display filter afterward to isolate SIP. The display filter for SIP is simply:

```
sip
```

### Finding your call

In a busy system, there might be dozens or hundreds of simultaneous calls. Finding the specific call you're investigating is the first challenge. There are several approaches.

If you know the caller or callee's number or extension, use a display filter:

```
sip contains "5551234567"
```

This shows every SIP message that contains that phone number anywhere in the message. Once you find the INVITE for your call, note the Call-ID from the headers. Then filter on that Call-ID to see every message in the dialog:

```
sip.Call-ID == "3848276298220188511@10.0.0.50"
```

### Wireshark's VoIP analysis features

Wireshark has a dedicated VoIP analysis view that's enormously helpful. Under the Telephony menu, select **Telephony > VoIP Calls** to see a list of all VoIP calls in the capture, combining SIP signaling with RTP stream information. You can select a call and click the "Flow Sequence" button to see its complete message sequence as a ladder diagram, the same visual representation we used in [post 3](/blog/first-call-flow-invite-to-bye), generated directly from the capture data. You can also click "Play Streams" to actually listen to the RTP audio from the capture. Being able to hear what the call sounded like is incredibly useful when debugging quality issues.

### Reading the ladder diagram

The ladder diagram view in Wireshark shows each SIP message as an arrow between the sending and receiving IP addresses, labeled with the method or response code. A normal completed call looks like this:

```
10.0.0.50             10.0.0.1             192.168.1.100
    |--- INVITE -------->|                      |
    |<-- 100 Trying ------|                      |
    |                     |--- INVITE ---------->|
    |                     |<-- 180 Ringing ------|
    |<-- 180 Ringing ------|                      |
    |                     |<-- 200 OK -----------|
    |<-- 200 OK -----------|                      |
    |--- ACK ------------>|                      |
    |                     |                      |
    |          [RTP flows between endpoints]     |
    |                     |                      |
    |--- BYE ------------>|                      |
    |                     |--- BYE ------------->|
    |                     |<-- 200 OK -----------|
    |<-- 200 OK -----------|                      |
```

When a call fails, the diagram will deviate from this pattern, and the deviation tells you what went wrong. An INVITE that goes out but gets no response at all (no 100 Trying, nothing) means the message isn't reaching the first hop. An INVITE that gets a 100 Trying from the proxy but nothing beyond that means the proxy can't reach the destination. A 4xx or 5xx final response tells you the call was explicitly rejected, and the code tells you why.

## sngrep

sngrep is a specialized SIP capture tool that runs in the terminal. It's faster and more focused than Wireshark for SIP analysis because it's designed specifically for SIP and nothing else. On many Linux based PBX systems, sngrep is the quickest way to see what's happening with SIP traffic in real time.

To install sngrep on a Debian or Ubuntu based system:

```
apt install sngrep
```

Launch it with:

```
sngrep
```

By default, sngrep captures on all interfaces and shows a list of SIP dialogs as they happen. Each row represents a call with the source, destination, method, and current status. You can filter in real time by pressing F7 and entering filter criteria.

Selecting a dialog and pressing Enter shows the ladder diagram for that call. Selecting a specific message in the ladder and pressing Enter shows the full SIP message content. This three level navigation, from call list to flow to message detail, makes it fast to drill from "which call had a problem" to "what exactly was in the message."

sngrep also supports reading from a pcap file:

```
sngrep -I capture.pcap
```

This is useful when someone has already captured traffic with tcpdump or Wireshark and you want to analyze the SIP content quickly. For a browser-based alternative, the [PCAP analyzer](/tools/pcap-analyzer) extracts SIP flows and RTP statistics from uploaded capture files without installing anything.

### Filtering sngrep

sngrep supports capture filters on the command line:

```
sngrep host 10.0.0.50
sngrep port 5060
sngrep host 10.0.0.50 and port 5060
```

You can also filter by SIP method or header content using the interactive filter (F7 key) once sngrep is running.

## PBX built in logging

Most PBX platforms have built in SIP debug logging that can be enabled without setting up a separate capture tool. This is often the first thing you have access to when troubleshooting because it doesn't require installing anything or setting up port mirroring.

### Asterisk

Enable SIP debug logging in the Asterisk CLI:

```
asterisk -rvvv
sip set debug on
```

Or for PJSIP (the newer SIP stack in Asterisk):

```
pjsip set logger on
```

This dumps every SIP message to the console in real time. The output is verbose but readable. Each message is shown with the full headers and body, prefixed by whether it was received or transmitted. You can filter the output by piping through grep to find specific Call-IDs, phone numbers, or response codes.

### FreeSWITCH

Enable SIP trace in FreeSWITCH:

```
sofia global siptrace on
```

Or for a specific profile:

```
sofia profile internal siptrace on
```

The output is similar to Asterisk: full SIP messages with direction indicators.

### 3CX

3CX provides SIP trace functionality through its management console. The trace output can be downloaded as a file and analyzed with sngrep or a text editor. 3CX also has a built in SIP log viewer that formats the messages and provides basic call flow visualization.

## Walking through example traces

Let's look at three scenarios to practice reading traces.

### Trace 1: Successful call (what normal looks like)

```
10.0.0.50 --> 10.0.0.1   INVITE sip:200@example.com
10.0.0.1  --> 10.0.0.50  SIP/2.0 100 Trying
10.0.0.1  --> 192.168.1.100  INVITE sip:200@192.168.1.100
192.168.1.100 --> 10.0.0.1   SIP/2.0 180 Ringing
10.0.0.1  --> 10.0.0.50  SIP/2.0 180 Ringing
192.168.1.100 --> 10.0.0.1   SIP/2.0 200 OK
10.0.0.1  --> 10.0.0.50  SIP/2.0 200 OK
10.0.0.50 --> 192.168.1.100  ACK
[RTP flows]
10.0.0.50 --> 10.0.0.1   BYE
10.0.0.1  --> 192.168.1.100  BYE
192.168.1.100 --> 10.0.0.1   SIP/2.0 200 OK
10.0.0.1  --> 10.0.0.50  SIP/2.0 200 OK
```

Every step is here: INVITE, 100, 180, 200, ACK, conversation, BYE, 200. This is what you're comparing against when something goes wrong.

### Trace 2: Call with no audio ([NAT](/blog/sip-nat-traversal) problem)

```
10.0.0.50 --> 10.0.0.1   INVITE sip:200@example.com
                          [SDP: c=IN IP4 10.0.0.50, m=audio 49170]
10.0.0.1  --> 10.0.0.50  SIP/2.0 100 Trying
10.0.0.1  --> 198.51.100.10  INVITE sip:200@198.51.100.10
                              [SDP: c=IN IP4 10.0.0.50, m=audio 49170]
198.51.100.10 --> 10.0.0.1   SIP/2.0 200 OK
                              [SDP: c=IN IP4 198.51.100.10, m=audio 3456]
10.0.0.1  --> 10.0.0.50  SIP/2.0 200 OK
10.0.0.50 --> 198.51.100.10  ACK
```

The call connected. Both sides sent 200 OK and ACK. But look at the [SDP](/blog/sdp-media-negotiation). Alice's INVITE has `c=IN IP4 10.0.0.50`, which is a private address. Bob's phone at 198.51.100.10 is on a different network. When Bob tries to send RTP to 10.0.0.50, that address is unreachable from his network. Result: Bob can't hear Alice. Meanwhile, Alice's SDP port 49170 might receive audio from Bob because Alice's NAT device might map incoming RTP to the right internal port (if the outbound RTP from Alice created a NAT mapping), or it might not. This is classic one way or no audio, and the problem is visible right there in the SDP.

### Trace 3: Failed [registration](/blog/sip-registration) (bad credentials)

```
10.0.0.50 --> 10.0.0.1   REGISTER sip:example.com
10.0.0.1  --> 10.0.0.50  SIP/2.0 401 Unauthorized
                          [WWW-Authenticate: Digest realm="example.com" nonce="abc123"]
10.0.0.50 --> 10.0.0.1   REGISTER sip:example.com
                          [Authorization: Digest username="alice" response="def456"]
10.0.0.1  --> 10.0.0.50  SIP/2.0 401 Unauthorized
                          [WWW-Authenticate: Digest realm="example.com" nonce="ghi789"]
10.0.0.50 --> 10.0.0.1   REGISTER sip:example.com
                          [Authorization: Digest username="alice" response="jkl012"]
10.0.0.1  --> 10.0.0.50  SIP/2.0 401 Unauthorized
```

The pattern is clear: the phone sends REGISTER, gets challenged, responds with credentials, and gets challenged again instead of getting a 200 OK. The credentials are wrong. The phone keeps trying because it doesn't distinguish between "you didn't authenticate" (the first 401) and "your authentication failed" (the subsequent 401s). The username "alice" is visible in the Authorization header, so you can verify it's what you expect. The password isn't visible, but you know it's wrong because the server keeps rejecting it.

## Tips for efficient trace reading

**Always start by finding the Call-ID.** Once you have it, you can filter everything else away and focus on the specific call. One caveat: the Call-ID is only guaranteed constant within a single dialog. If the call passes through a B2BUA, an SBC or most PBX platforms (RFC 7092 catalogs the varieties), each leg is a separate dialog with its own Call-ID. When a capture spans both sides of such a device, correlate the legs by timestamps, the phone numbers in the To/From URIs, and the SDP addresses rather than expecting one Call-ID end to end.

**Check timestamps.** The time between an INVITE and a 100 Trying should be milliseconds. If it's seconds, there's a network delay. The time between 180 Ringing and 200 OK tells you how long the phone rang before someone answered.

**Look at both sides when possible.** A capture from only one side of the conversation shows you what that side sent and received, but doesn't show you what happened at the other end. If possible, capture at both the caller and callee simultaneously. This reveals problems in the middle, like headers being modified by a proxy, or a B2BUA rewriting Call-ID, tags, Contact, and SDP as it re-originates the call on the far leg.

**Save your captures.** When you're troubleshooting a call issue, start the capture before reproducing the problem and stop it after. Save the capture file. If you need to escalate to a vendor or provider, the capture file is the single most useful thing you can give them.

---

*Drowning in a capture rather than short of tools? [How to Find the Failing Call in a Huge SIP Trace](/blog/reading-sip-traces-without-losing-your-mind) is the filtering workflow for cutting thousands of messages down to the one dialog that matters.*

*Next up: [Common SIP Problems and What They Look Like](/blog/common-sip-problems), a symptom based troubleshooting reference for the problems you'll encounter most often.*

---

### Part 12: Common SIP Problems and What They Look Like

URL: https://voiptest.com/blog/common-sip-problems
Published: 2026-04-18
Tags: sip, troubleshooting, one-way-audio, registration, nat, voip, reference

*SIP Signaling From the Wire Up: Part 12 of 12*

This is the reference post. Every section starts with a symptom, the thing the user or administrator is reporting, and works through the most likely SIP level causes, what you'd see in a trace, and where to look. If you're reading this at 10 PM while troubleshooting a ticket, jump straight to the symptom that matches and work from there.

## [One way audio](/blog/one-way-audio)

**Symptom:** The call connects. One party can hear the other, but not vice versa.

**Most likely cause:** NAT traversal failure. This is the single most common SIP problem in existence, and we covered it extensively in [post 6](/blog/sip-nat-traversal).

**What to look for in the trace:** Pull the SDP from both the INVITE and the 200 OK. Check the `c=` lines. If either one contains a private IP address (10.x, 172.16 through 172.31, 192.168.x) and the other party is on a different network, that's your answer. The private address is unreachable from the remote end, so RTP in one direction has nowhere to go.

Also check whether SIP ALG is modifying the SDP. Capture on both sides of the router and compare. If the SDP changes as it passes through the NAT device, ALG is active and may be rewriting addresses incorrectly.

**Less common causes:**
- Firewall blocking RTP in one direction. RTP typically uses UDP on a range of high ports (often 10000 through 20000, but the range is a configuration choice on your phones or PBX, not a standard; check what your system actually uses and what the SDP advertises). If a firewall allows outbound UDP but blocks inbound UDP on those ports, only one direction of audio will work.
- Asymmetric routing. The SIP signaling takes one path and the RTP takes another, and the return path for RTP is blocked.
- Codec mismatch on one direction. Rare, but possible if one side is sending with a codec the other side didn't negotiate.

**Fix:** Disable SIP ALG on the router. Configure STUN on the phones or PBX. Ensure the firewall allows bidirectional UDP traffic on the RTP port range. If an SBC is available, use it.

## No audio in either direction

**Symptom:** The call connects (both parties see the call as active on their phone displays), but neither party can hear anything. Complete silence.

**Most likely cause:** Same NAT and firewall issues as one way audio, but affecting both directions. This happens when both endpoints are behind NAT devices that aren't handling RTP correctly, or when a firewall is blocking all RTP traffic.

**What to look for in the trace:** Same SDP checks as one way audio, but verify both sides. If both `c=` lines show private addresses and both parties are on different networks, neither direction of RTP will work.

Also check for an RTP/SRTP mismatch. If one side negotiated SRTP (`m=audio 49170 RTP/SAVP`) and the other side negotiated plain RTP (`m=audio 3456 RTP/AVP`), the two sides are speaking different protocols. The encrypted side can't decode the unencrypted stream, and vice versa. In the SDP, look at the transport protocol on the `m=` line. Both sides need to match.

**Another possibility:** The `c=` line is set to `0.0.0.0`. Some older hold implementations use this address, and a bug or misconfiguration might cause it to appear in the initial call setup SDP. An address of 0.0.0.0 means "don't send me any media," so both sides obey and nobody hears anything.

## Calls dropping after exactly 30 seconds

**Symptom:** The call connects and audio works, but the call is automatically disconnected after approximately 30 seconds. The timing is very consistent. (For a deeper look at this specific issue, see [Calls Dropping After a Set Time](/blog/calls-dropping-after-set-time).)

**Most likely cause:** The ACK for the 200 OK never reached the callee. When the callee's phone sends a 200 OK to an INVITE, it starts a retransmission timer. If it doesn't receive an ACK within a certain period (which is typically around 32 seconds, based on the 64*T1 retransmission timeout for 2xx responses to INVITE per RFC 3261 Section 13.3.1.4), it assumes the 200 OK was never received and tears down the call.

**What to look for in the trace:** Capture on the callee's side. You should see the 200 OK being sent, then retransmitted several times at increasing intervals, and then a BYE after the timer expires. If the ACK isn't appearing in the capture at the callee's end, something is blocking it. Check the proxy or SBC in between. The ACK might be routed differently than the original INVITE (since ACK for 2xx responses can be sent directly end to end rather than through the proxy), and a firewall might block the direct path.

**Another possibility:** SIP session timers (RFC 4028). If the call has session timer headers (Session-Expires, Min-SE), both sides agree to periodically refresh the session with a re-INVITE or UPDATE. If the refresh fails (the re-INVITE is blocked or the response is lost), the session timer expires and the call drops. The timing would match the Session-Expires value in the headers. RFC 4028 sets 90 seconds as the minimum session interval (the default Min-SE) and recommends 1800 seconds as the default Session-Expires, but the value actually in effect is whatever your provider or PBX negotiated; read it out of the headers in the trace rather than assuming a common value.

## Phone shows "not registered" or calls go straight to voicemail

**Symptom:** The phone doesn't ring for incoming calls. The display may show a registration error, or it may appear normal while incoming calls [go to voicemail](/blog/calls-going-to-voicemail) or get a "user not available" message.

**Most likely cause:** Registration failure. The phone either can't register at all or its registration has expired without being renewed.

**What to look for in the trace:** Filter for REGISTER messages from the phone's IP. You should see the registration sequence: REGISTER, 401, REGISTER with Authorization, 200 OK. If you see REGISTER going out but no response coming back, the messages aren't reaching the server or the responses aren't reaching the phone. Firewall or routing issue.

If you see the 401 challenge/response cycle repeating without ever getting a 200 OK, the credentials are wrong. Compare the `username` in the Authorization header against what's configured on the server.

If registration appears to succeed (you see a 200 OK) but the phone still can't receive calls, the problem might be a stale NAT mapping. The phone registered successfully, the server recorded the Contact address, but the NAT mapping between the phone's private address and its public address has expired. When the server tries to route an inbound call to the Contact address, the NAT device has no mapping for that traffic and drops it. Look at the time between registrations and compare it against the NAT device's UDP timeout. If the registration interval is longer than the NAT timeout, reduce the registration interval or enable SIP keep alives.

**Also check DNS.** If the phone is configured with a domain name for the registrar and DNS resolution is failing, no REGISTER will be sent at all. The phone's own logs (not the SIP trace) will show a DNS error in this case.

## Call connects but immediately disconnects

**Symptom:** The phone rings, the callee answers, and the call drops within a second or two. Sometimes the callee hears a brief click before silence.

**Most likely cause:** The 200 OK from the callee triggered a process on the proxy or SBC that immediately terminated the call. This can happen due to a routing loop where the INVITE is being forwarded back to the originator, a policy rejection at a proxy that happens post-answer, or a TLS handshake failure on a downstream leg.

**What to look for in the trace:** Find the 200 OK and then look at what immediately follows. If there's a BYE within seconds of the 200 OK, check who sent the BYE and why. If the proxy sent it, the proxy's logs will typically explain the reason (loop detected, policy violation, license limit reached).

Also check for a 408 timeout on a related transaction. Some PBX systems set up multiple legs simultaneously (for example, ringing the desk phone and the mobile app at the same time). If one leg answers but the PBX can't properly cancel the other leg, it might tear down the whole call.

## Echo or feedback

**Symptom:** One or both parties hear their own voice echoed back with a slight delay, or there's a hollow, reverberant quality to the audio.

**What this has to do with SIP:** Echo is primarily an audio path problem, not a signaling problem, but the SDP negotiation can contribute.

If the negotiated codec has a long packetization time (check `a=ptime` in the SDP), [echo](/blog/echo-on-voip-calls) becomes more noticeable because each audio frame covers a longer duration and the jitter buffer adds more delay. Longer delay means the echo return path is longer, which makes echo more perceptible. Reducing ptime from 30 to 20 milliseconds can help.

If the call traverses a gateway between VoIP and the traditional phone network, the gateway's echo cancellation might be insufficient. Hybrid echo occurs at the 2-wire to 4-wire conversion point in the PSTN, and if the gateway's echo canceller isn't properly calibrated, the echo leaks through to the VoIP side.

Acoustic echo is caused by audio from the phone's speaker being picked up by its microphone, which is entirely a hardware problem. Speakerphones are the worst offenders. The SDP can't cause or fix this.

**What to check in the trace:** The codec and ptime negotiated in SDP. If one side is using a ptime of 30 or higher, try reducing it. If the call goes through a PSTN gateway, the gateway's echo cancellation settings are the more likely culprit than anything in the SIP signaling.

## Caller ID not displaying correctly

**Symptom:** The callee sees the wrong [caller ID](/blog/caller-id-problems), no caller ID, or "unknown" instead of the expected name and number.

**What to look for in the trace:** SIP carries caller identity in multiple places, and different systems look at different headers:

**From header** is the basic SIP identity. This is what the calling phone sets, and it can be set to anything. Many PBX systems allow administrative control over the From header on outbound trunk calls.

**P-Asserted-Identity** is an identity asserted by a trusted intermediary. The SIP trunk provider or PBX adds this header to attest that the caller identity has been verified. Some carriers use this for caller ID display.

**Remote-Party-ID** is an older header that serves a similar purpose to P-Asserted-Identity. Some systems still use it.

```
From: "Main Office" <sip:+15559876543@example.com>;tag=as1234
P-Asserted-Identity: <sip:+15559876543@provider.com>
Remote-Party-ID: <sip:+15559876543@provider.com>;screen=yes;party=calling
```

If the outbound caller ID is wrong, check what your PBX is putting in the From header and the P-Asserted-Identity header (if present). If the PBX is sending the right number but the far end sees something different, the SIP trunk provider's SBC might be overriding it with whatever number is on file for your account. Contact the trunk provider and verify what caller ID they're configured to present for your trunk.

For inbound calls where caller ID isn't showing, check the From header in the incoming INVITE. If the From contains just a number (no display name), the callee's phone might display just the number. Caller name (CNAM) lookup is a separate process from SIP and is handled by the terminating carrier or a CNAM database lookup. The name you see (or don't see) for incoming calls is often not in the SIP message at all.

## Transfers failing

**Symptom:** When a user tries to transfer a call, the transfer fails. The original caller might get disconnected, or the transfer might not complete and the caller stays connected to the original agent.

**What to look for in the trace:** Find the REFER message. If there's no REFER in the trace, the phone isn't sending one, which could be a phone configuration issue or the phone doesn't support REFER.

If the REFER is sent, look for the response. A 202 Accepted means the transfer is being attempted. A 405 Method Not Allowed means the receiving end doesn't support REFER. A 403 means the transfer was rejected by policy.

After the 202, look for NOTIFY messages. These report the progress of the transfer. The NOTIFY body contains a SIP response code indicating what happened when the transferred party tried to connect to the transfer target. A NOTIFY containing "SIP/2.0 200 OK" means the transfer succeeded. A NOTIFY containing "SIP/2.0 486 Busy" means the transfer target was busy. A NOTIFY containing "SIP/2.0 408 Request Timeout" means the transfer target didn't answer.

If the REFER and NOTIFY sequence looks correct but the call still drops, the issue might be in the Replaces header for attended transfers. The Replaces header tells the transfer target which existing call leg to replace. If the Replaces header is malformed or the target doesn't support it, the transfer fails even though the SIP mechanics appeared to work.

Transfers across different PBX platforms or through SBCs that don't properly relay REFER are a common pain point. If you're seeing consistent transfer failures between two specific systems, it's likely an interoperability issue with how those systems handle REFER and Replaces.

## Call quality degrades at specific times

**Symptom:** Calls work fine in the morning but develop choppy audio, delays, or dropouts in the afternoon.

**This is typically not a SIP problem.** The SIP signaling for a call established at 9 AM and a call established at 3 PM looks identical. The difference is in the network conditions when the RTP audio is flowing. This is an ISP congestion issue, a local network saturation issue, or a QoS configuration issue, all of which are covered in the other blog series. One caveat when you investigate: ping and traceroute use ICMP, which routers often deprioritize or rate-limit, so their latency and loss numbers are indicative rather than proof; a measurement that rides the actual RTP path (RFC 3550), or RTP statistics from the PBX itself, reflects what the voice packets really experienced.

However, there's one SIP adjacent thing to check. If your PBX is transcoding (converting between codecs on different call legs), heavy call volume during peak hours increases the transcoding load on the PBX. A PBX that handles 10 transcoded calls fine in the morning might struggle with 40 at peak. Check the PBX's CPU usage during the problem periods and compare the codecs on the internal versus trunk SDP to see if transcoding is involved.

## Where to go from here

If you've made it through this entire series, you now have a working understanding of SIP signaling from the protocol fundamentals through practical troubleshooting. You can read a SIP message, follow a call flow, understand registration, SDP negotiation, NAT traversal, and the security model. You know what tools to use and what to look for when something breaks.

The next step is practice. The next time a call has a problem, capture the traffic. If the capture feels overwhelming, [Reading a SIP Trace Without Losing Your Mind](/blog/reading-sip-traces-without-losing-your-mind) covers how to filter out the keep-alive noise and isolate the one call that matters. Look at the SIP messages, or upload a capture to the [SIP call stories tool](/tools/sip-call-stories) for a plain-English breakdown of what happened. Compare what you see against what you now know a normal call looks like. Each real world problem you work through reinforces the concepts and builds pattern recognition that makes you faster at finding the root cause.

SIP is a deep protocol with a lot of extensions, edge cases, and vendor specific behaviors that go beyond what any single series can cover. But the fundamentals covered here are the foundation that everything else builds on, and they'll serve you well in the vast majority of real world troubleshooting situations.

---

*This is the final post in the SIP Signaling From the Wire Up series. If you're looking for more foundational VoIP knowledge, the [VoIP From the Ground Up](/blog/series/voip-from-the-ground-up) series covers voice technology from the basics. If your investigation points to the internet connection as the problem, the [Getting the Internet Right](/blog/isp-foundation) series covers business internet selection and evaluation.*

---

## Series: When Your Phones Sound Bad

A 12-part VoIP troubleshooting guide covering the most common call quality problems. Symptom-based diagnosis for choppy audio, one-way audio, dropped calls, echo, caller ID issues, and more.

### Part 1: Choppy or Robotic Audio on VoIP Calls

URL: https://voiptest.com/blog/choppy-robotic-audio
Published: 2026-04-19
Tags: voip-troubleshooting, choppy-audio, jitter, packet-loss, call-quality

*When Your Phones Sound Bad: Part 1 of 12*

Choppy audio is probably the most common VoIP complaint there is. The person on the other end sounds like they're talking through a fan, or their words are breaking up into fragments, or the audio has a stuttering, robotic quality that makes it hard to follow the conversation. It might happen on every call or just some calls. It might last for the entire conversation or come and go in waves.

The frustrating thing about choppy audio is that it has multiple possible causes, and those causes can live in different parts of the chain. But the list of likely culprits is actually shorter than most people think, and you can work through them systematically.

## What's actually happening

When audio sounds choppy or robotic, what you're hearing is the result of one of two things: packets arriving late ([jitter](/blog/what-is-jitter-and-why-it-matters)) or packets not arriving at all ([packet loss](/blog/understanding-voip-packet-loss)). Sometimes both.

VoIP calls work by breaking audio into small chunks, typically 20 milliseconds each, packaging each chunk into a data packet, and sending those packets across the network. On the receiving end, the phone collects those packets and plays them back in sequence to reconstruct the audio. If a packet arrives late or doesn't arrive at all, the phone has to either skip that chunk of audio or try to guess what the missing audio sounded like. Neither option sounds good. Skipped chunks produce gaps and choppiness. Bad guesses produce that distinctive robotic or warbling quality.

## Check 1: Is it happening on all calls or just some?

This is the first question to ask because it immediately narrows the investigation.

If every call sounds choppy, the problem is almost certainly on your end. Something in your local network, your internet connection, or your phone equipment is consistently degrading the audio. This is actually the easier scenario to troubleshoot because the problem is reproducible and within your control.

If only some calls are choppy, the pattern matters. Calls to a specific person or number might indicate a problem on the far end. Calls that are fine in the morning but bad in the afternoon might indicate ISP congestion during peak hours. Calls that are choppy only when certain other activities are happening (large file transfers, cloud backups, video streaming) point to bandwidth saturation on your network.

## Check 2: WiFi

If the phone experiencing choppy audio is connected over WiFi, that's the first thing to address. [WiFi and VoIP are a bad combination](/blog/wired-vs-wifi-for-voip), and this is the single most common cause of choppy audio in offices that use wireless phones, softphones on laptops, or desktop phones connected through WiFi adapters.

WiFi introduces jitter because the wireless medium is shared and contended. Your phone's packets have to compete with every other device on the same WiFi network for airtime. When the access point is busy serving other clients, your phone's packets wait in a queue. That waiting introduces variable delay, which is jitter by definition. WiFi also retransmits packets that get corrupted by interference, which adds more variable delay.

The fix is simple in concept: use a wired Ethernet connection for any device that carries voice. Plug the phone into a switch port with a cable. If the phone is a softphone on a laptop, connect the laptop to Ethernet when making calls. This single change eliminates WiFi as a variable and resolves the problem in a remarkable number of cases.

If wired connections aren't practical (some office layouts make it genuinely difficult), you can improve WiFi performance for voice by ensuring the access points support band steering to 5 GHz, reducing the number of clients per access point, enabling WMM (WiFi Multimedia) QoS on the access points, and placing access points close enough that signal strength is strong throughout the office. But a wired connection will always be more consistent than WiFi for voice traffic.

## Check 3: Bandwidth saturation

Your internet connection has a limited amount of capacity, and when that capacity is fully used, new packets get delayed or dropped. This affects everything on the network, but voice traffic shows the symptoms first because it's the most sensitive to delays and losses.

The direction that matters most for voice is upload. When you're on a call, your outbound audio is traveling on your upload bandwidth. If your upload is saturated by other traffic, your voice packets get queued behind everything else, or they get dropped entirely.

This is especially common on connections with asymmetric speeds, which includes most cable and DSL connections. A cable plan might give you 300 Mbps download and 20 Mbps upload. The download is rarely the problem. But 20 Mbps of upload can get saturated faster than you'd expect when you add up VoIP calls, video conferences, cloud backups, file uploads, email attachments, and all the other outbound traffic from your office.

To check for this, run a speed test during the times when choppy audio is occurring. Pay attention to the upload speed specifically. Compare it to what you're paying for. If the upload speed is significantly lower than expected, your connection may be congested. If the speed looks normal on the test, try running the test while the problem is actively happening, because a speed test taken during a quiet moment won't show congestion that only occurs during busy periods.

Also check whether any scheduled tasks are consuming upload bandwidth during business hours. Cloud backup services, file sync applications, software update distribution, and security camera footage uploads are common culprits. These can often be scheduled for off hours or throttled during business hours.

## Check 4: QoS (Quality of Service) configuration

QoS is a feature on routers and managed switches that prioritizes certain types of traffic over others. When QoS is configured for VoIP, the router identifies voice packets and gives them priority over other traffic. This means that even when the connection is busy, voice packets get through without waiting in line.

If your router supports QoS and it's not configured, voice packets are treated the same as everything else. During periods of congestion, voice packets get delayed right alongside file downloads and web browsing. Configuring QoS to prioritize voice traffic can make a significant difference on connections that are anywhere near their capacity limits.

Most business routers support some form of QoS. The implementation varies by manufacturer, but the general concept is the same: you define a rule that identifies VoIP traffic (usually by port range, DSCP marking, or the IP address of the phone system) and assign it to a high priority queue. The router then ensures that high priority traffic is sent before lower priority traffic when there's contention for bandwidth.

If your PBX or phones tag voice packets with [DSCP markings](/blog/quality-of-service-explained) (most do by default, using EF, Expedited Forwarding, which is DSCP value 46), your router needs to be configured to honor those markings and prioritize accordingly. If the router ignores DSCP markings, the tagging is meaningless.

## Check 5: Local network issues

Problems inside your office network can cause choppy audio even when your internet connection is fine. The chain between your phone and your router includes Ethernet cables, switches, and potentially other network equipment, and any of these can introduce problems.

**Bad cables.** An Ethernet cable with a damaged connector, a kink, or internal wire damage can cause packet loss and errors that affect voice quality. These problems can be intermittent, showing up when the cable is moved or when temperature changes cause slight expansion and contraction. If choppy audio is isolated to a specific phone, try replacing the Ethernet cable.

**Overloaded switches.** Cheap, unmanaged consumer switches don't handle traffic prioritization. If a switch is handling traffic from a busy computer and a phone at the same time, the phone's packets can be delayed. Business grade managed switches support VLANs and QoS, which allow you to separate voice traffic onto its own virtual network segment with priority handling. If you're running phones and computers through the same consumer switch, upgrading to a managed switch with VLAN support is one of the more effective improvements you can make.

**Duplex mismatches.** If a switch port ends up in half duplex mode, the port can only send or receive at any given moment, not both simultaneously, which causes collisions and retransmissions that introduce jitter. With modern equipment and autonegotiation left enabled on both ends, this is now uncommon; it mostly appears when one side has been manually forced to full duplex while the other is left to autonegotiate. Before blaming duplex, verify it in the switch's port counters: a genuine mismatch shows up as late collisions, FCS errors, and runts on the affected port. If the counters are clean and the port shows full duplex at 100 Mbps or 1 Gbps, look elsewhere.

## Check 6: The phone itself

Sometimes the phone hardware is the issue. A phone with a failing network interface can cause packet loss at the device level. A phone that's overheating (placed on top of a warm docking station or in direct sunlight) can behave erratically. A phone with outdated firmware might have known bugs that affect audio processing.

Check whether the phone manufacturer has released firmware updates. VoIP phone manufacturers regularly release updates that fix audio processing bugs, improve jitter buffer algorithms, and address codec issues. Running old firmware means running known problems that have already been fixed.

## Check 7: Your internet connection

If you've checked everything on the local side and the problem persists, the issue may be with the internet connection itself. As covered in the [Getting the Internet Right](/blog/isp-foundation) series, not all internet connections are equally suitable for voice traffic.

Cable connections can experience congestion during peak hours because of their shared bandwidth nature. DSL connections can develop intermittent issues from degraded copper. Even fiber connections can have problems if there's an issue with the handoff equipment or the provider's backbone.

Run an extended ping test to a reliable external host (your VoIP provider's server address is ideal) and look at the results over a period of minutes. Better yet, run our [VoIP quality test](/tools/voip-test), which sends traffic that matches actual voice patterns rather than ICMP pings. As rules of thumb rather than universal pass/fail lines (the audible impact of jitter depends on the codec and how the endpoint's jitter buffer adapts, and reported jitter is itself a statistical estimate defined by RFC 3550), round-trip latency spikes above 100 milliseconds, jitter sustained above 20 to 30 milliseconds, or packet loss above 0.5% are signs that your internet connection is likely contributing to the problem.

If the connection consistently shows poor metrics during business hours but looks fine at night, that's a congestion pattern and it points to either your ISP's infrastructure being overloaded or your own outbound traffic saturating the upload.

## Working through it systematically

The key to solving choppy audio is working through these checks in order rather than guessing. Start with WiFi (because it's the most common cause and the easiest to test by plugging in a cable). Move to bandwidth and QoS. Then check local network equipment. Then look at the phone hardware and firmware. Then evaluate the internet connection.

Each check is a process of elimination. When you eliminate a possible cause, you've narrowed the problem. When you find something that's clearly wrong, fix it and test again before continuing down the list. Many choppy audio issues have more than one contributing factor, and sometimes fixing the biggest one is enough even if a smaller issue remains.

*Next up: [One Way Audio: I Can Hear Them But They Can't Hear Me](/blog/one-way-audio), the second most common VoIP complaint and the specific causes behind it.*

---

### Part 2: One Way Audio: I Can Hear Them But They Can't Hear Me

URL: https://voiptest.com/blog/one-way-audio
Published: 2026-04-20
Tags: voip-troubleshooting, one-way-audio, nat, firewall, sip-alg

*When Your Phones Sound Bad: Part 2 of 12*

One way audio is one of the most distinctive VoIP problems. The call connects, one person can hear the other perfectly fine, but the audio only goes in one direction. Sometimes the caller can hear the callee but not vice versa. Sometimes it's the other way around. Sometimes neither side can hear anything at all, which is technically zero way audio but often gets reported as "the call connected but nobody could hear anything."

Unlike choppy audio, which can have a dozen different causes, one way audio has a much shorter list of likely culprits. And the most common one by far is a NAT or firewall issue. If you're experiencing one way audio, the NAT problem described in the first section of this post is the most likely explanation. And unlike a guess, it's one a packet capture can confirm directly.

## The NAT problem (the most common cause)

NAT stands for Network Address Translation, and it's how your office router allows multiple devices to share a single public internet address. It works transparently for web browsing, email, and most internet activity. It does not work transparently for VoIP, and the reason is technical but worth understanding because it explains exactly why one way audio happens.

When you place a VoIP call, your phone tells the other end where to send audio. It does this by embedding its own IP address and a port number inside the call setup messages (specifically in something called SDP, which is covered in detail in the [SIP Signaling series](/blog/sdp-media-negotiation)). The problem is that your phone knows its own local IP address, which is a private address like 10.0.0.50 or 192.168.1.25. That private address only works inside your office network. When the other end receives the call setup and tries to send audio to that private address, the packets have nowhere to go because that address doesn't exist on the public internet.

The result is that audio flows in one direction but not the other. Your phone can send audio to the other party (because your outbound traffic passes through NAT and gets translated to your public address), but the other party can't send audio back to you (because they're trying to reach your private address, which is unreachable from outside your network).

The good news is that this failure leaves evidence you can check directly. The SDP offer/answer (RFC 3264) carries the media address in [its `c=` line](https://www.rfc-editor.org/rfc/rfc4566.html), so pull the SDP from the INVITE and the 200 OK in a capture: a private address (10.x, 172.16 through 172.31, 192.168.x) advertised toward a remote network is the smoking gun. Then look at the RTP streams themselves (RFC 3550): a capture that shows RTP leaving your network but none arriving, or arriving but addressed somewhere unreachable, tells you which direction is broken and which device to look at next.

This is such a common problem that there's an entire post in the SIP series dedicated to [NAT traversal](/blog/sip-nat-traversal). But from a troubleshooting perspective, here's what to do about it.

### Turn off SIP ALG

SIP ALG (Application Layer Gateway) is a feature in many routers that tries to fix the NAT problem by inspecting VoIP traffic and rewriting the embedded IP addresses. In theory, this should make things work. In practice, [SIP ALG implementations are notoriously buggy](/blog/sip-alg-the-setting-that-breaks-everything) and cause more problems than they solve, and most VoIP providers recommend turning it off. The definitive check is a capture on both sides of the router: compare the SDP as it left the phone with the SDP that arrived at the far side. If the `c=` line address or media port changed in transit, the ALG is rewriting the offer/answer, and if it's rewriting it incorrectly, you've localized the fault.

The challenge is finding it. Different router manufacturers call this feature different names: SIP ALG, SIP Helper, SIP Passthrough, or it might be buried under an Application Layer Gateway menu. Some routers have it enabled by default with no obvious way to disable it. If your router doesn't have a clear option to turn it off, check the manufacturer's documentation or support forums.

After disabling SIP ALG, restart the router and the phones. Test calls again. In a surprising number of cases, this single change resolves one way audio.

### Check firewall rules

If SIP ALG isn't the issue (or is already disabled), the next thing to check is your [firewall](/blog/your-local-network). VoIP uses two separate streams of traffic: SIP for the call signaling (usually on UDP port 5060) and RTP for the actual audio (usually on a range of UDP ports, commonly 10000 through 20000, though the exact range varies by phone and PBX configuration).

A firewall might allow the SIP signaling through (so the call connects) but block the RTP audio (so nobody can hear anything). Or it might allow RTP in one direction but not the other. Check that your firewall allows bidirectional UDP traffic on both the SIP port and the full RTP port range used by your phones.

If you're not sure what port range your phones or PBX use for RTP, check the PBX configuration. Asterisk, for example, defaults to ports 10000 through 20000. FreeSWITCH uses 16384 through 32768. 3CX has its own configurable range. Your firewall needs to permit traffic on whatever range your system uses.

### Configure STUN on your phones

[STUN (Session Traversal Utilities for NAT)](https://www.rfc-editor.org/rfc/rfc8489.html) helps phones discover their own public IP address so they can include it in the call setup messages instead of their private address. When STUN is configured, the phone queries a STUN server before placing a call, learns its public address, and uses that address in the SDP. The remote end then sends audio to the correct public address, which passes through NAT and reaches the phone.

Most VoIP phones have a STUN setting in their configuration. Your VoIP provider may operate a STUN server and provide the address in their setup documentation. Common public STUN servers also exist, though using your provider's server is preferred.

Note that STUN doesn't work in all NAT scenarios. Specifically, it fails with symmetric NAT (address- and port-dependent mapping, in [the vocabulary RFC 4787 introduced](https://www.rfc-editor.org/rfc/rfc4787.html) to replace the old cone/symmetric terms), where the router assigns different public ports for different destinations. Modern endpoints and softphones increasingly use ICE (RFC 8445), which gathers multiple candidate addresses and verifies connectivity on each pair before media flows, more robust than STUN alone where both sides support it. If neither resolves the issue, your VoIP provider may need to use a different NAT traversal method on their end, or you may need to use a router that provides better NAT behavior for VoIP.

## Firewall on the phone itself or the computer

If you're using a softphone (a VoIP application on a computer rather than a hardware desk phone), the computer's own firewall can block RTP traffic. Windows Firewall, macOS firewall, or third party security software might block the softphone's audio ports even though the signaling gets through.

Check whether the softphone application has been granted firewall exceptions. On Windows, check both the Windows Firewall settings and any third party antivirus or security suite that includes its own firewall. The symptom is the same as a network firewall issue: the call connects but audio doesn't flow in one or both directions.

## VPN and one way audio

If the person experiencing one way audio is connected through a VPN, the VPN itself is a very likely culprit. VPNs create an encrypted tunnel for all network traffic, and the way they handle UDP traffic (which VoIP uses) can cause audio problems.

When a phone or softphone sends audio through a VPN, the packets have to be encrypted, encapsulated in the VPN tunnel, sent to the VPN endpoint, decrypted, and then forwarded to the destination. This process can change the apparent source address of the audio packets, interfere with NAT traversal, and add latency. Many VPN configurations are simply not designed to handle real time audio well.

If VoIP calls need to work over a VPN, the VPN needs to be configured to handle UDP traffic properly, and the VoIP traffic might need to be excluded from the VPN tunnel entirely (a configuration called split tunneling, where VoIP traffic goes directly to the internet while other traffic goes through the VPN). This is a common configuration in hybrid and remote work setups and is covered in more detail in the [Working From Home](/blog/voip-quality-for-remote-teams) series.

## Codec mismatch

A less common but possible cause of one way or no audio is a [codec mismatch](/blog/how-codecs-shape-call-quality). A codec is the algorithm that encodes and decodes voice audio into digital data. Both sides of a call need to agree on a codec. If they can't agree (or if they nominally agree but one side can't actually process the agreed codec), audio doesn't flow.

In most configurations, codec negotiation happens automatically and works fine. But misconfigurations can occur. If a PBX is configured to offer only G.729 and the remote end only supports G.711, no common codec exists and the call either fails entirely or connects with no audio.

If you suspect a codec issue, check the codec settings on your PBX and phones. Ensure that at least one common codec (G.711 is the safest universal option) is enabled on all devices and trunk connections.

## Network asymmetry

In some network configurations, the path that outbound traffic takes is different from the path that inbound traffic takes. This is called asymmetric routing. If the inbound path is blocked or broken while the outbound path works, audio flows in one direction but not the other.

This is most common in complex network setups with multiple internet connections, multiple routers, or policy based routing rules. If your network has any of these, check whether the routing for UDP traffic (particularly on the RTP port range) is symmetric, meaning inbound and outbound traffic follow the same path through the same router and firewall.

## The troubleshooting order

For one way audio, work through this checklist:

1. Disable SIP ALG on the router
2. Verify firewall rules allow bidirectional UDP on SIP and RTP ports
3. Configure STUN on the phones if not already set
4. Check for computer firewalls or security software blocking the softphone
5. If using a VPN, test without the VPN to isolate
6. Verify codec configuration matches between endpoints
7. Check for asymmetric routing in complex network setups

In the majority of cases, the first three steps resolve the problem. One way audio is usually a NAT or firewall issue. The challenge is finding exactly where in the chain the blockage is, not figuring out the general category of problem, and that is exactly what the SDP addresses and RTP flow directions in a capture are for.

*Next up: [Calls Dropping After a Set Amount of Time](/blog/calls-dropping-after-set-time), why your calls disconnect at exactly 30 seconds, 15 minutes, or some other suspiciously consistent interval.*

---

### Part 3: Calls Dropping After a Set Amount of Time

URL: https://voiptest.com/blog/calls-dropping-after-set-time
Published: 2026-04-21
Tags: voip-troubleshooting, dropped-calls, nat-timeout, session-timers, call-quality

*When Your Phones Sound Bad: Part 3 of 12*

When VoIP calls drop, they usually fall into one of two patterns. Either they drop randomly and unpredictably, or they drop at a suspiciously consistent interval. The consistent interval is actually the more useful clue because it points to specific causes. A call that drops at exactly 30 seconds is telling you something very different than a call that drops at exactly 15 minutes, and both are different from calls that drop at random times.

This post covers the timer based drops first (because the interval is the diagnosis) and then the random drops.

## Calls dropping at exactly 30 to 32 seconds

This is one of the most recognizable patterns in VoIP troubleshooting. The call connects, audio works, and then at almost exactly 30 to 32 seconds the call disconnects. Every time.

The most common cause is a missing ACK. When someone answers a VoIP call, their phone sends a 200 OK message. The caller's phone is supposed to respond with an [ACK](/blog/first-call-flow-invite-to-bye) to confirm it received the 200 OK. If the ACK never arrives, the answering phone doesn't know whether the caller actually received the answer. Its UAS core retransmits the 200 OK, and if it still doesn't get an ACK after 64×T1, 32 seconds at the default T1 of 500 ms (RFC 3261 Section 13.3.1.4), it gives up and tears down the call. (A note for the pedants reading traces: Timer H, which also happens to run 32 seconds, belongs to the *non-2xx* INVITE server transaction in Section 17.2.1. Retransmission of a 2xx to an INVITE is handled by the UAS core, which is why the 200 OK case is specified separately.) Because NAT behavior, media-inactivity timers, application timers, and provider policy can also produce fixed-interval drops in the same neighborhood, a packet capture should confirm the missing ACK before you commit to that diagnosis.

The ACK is being sent by the caller's phone. The question is why it's not arriving at the callee's phone. Common reasons include:

**A firewall or NAT device is blocking the ACK.** The initial INVITE and the 200 OK made it through because they were part of an established transaction that the NAT device was tracking. But the ACK might be routed differently (in some SIP implementations, the ACK for a 2xx response goes directly end to end rather than through the proxy), and if the direct path is blocked, the ACK is lost.

**SIP ALG is mangling the routing information.** If SIP ALG on the router is rewriting addresses in the call setup messages, the ACK might be addressed to a location that doesn't match what the callee's phone expects. The ACK is sent but to the wrong address.

**The proxy or PBX is not forwarding the ACK correctly.** If the proxy or PBX sits in the signaling path and has a bug or misconfiguration related to ACK handling, the ACK might be absorbed without being forwarded to the callee.

The fix follows the standard approach: disable SIP ALG, verify firewall rules, and check the PBX or proxy configuration. If you have access to SIP debug logging on the callee's phone or PBX, look for whether the ACK is arriving. If it's not, capture traffic on the callee's network to see if the ACK is reaching the network at all or being lost somewhere upstream.

## Calls dropping at 15 minutes (or another longer interval)

If calls consistently drop at longer intervals like 15 minutes, 30 minutes, or an hour, the likely culprit is a SIP session timer or a NAT timeout.

**[SIP session timers](/blog/sip-call-features)** (RFC 4028) are a mechanism where both parties agree to periodically refresh the call session. The idea is to ensure that both sides are still present and that the call is still active. The refresh happens through a re-INVITE or UPDATE message sent at intervals specified in the Session-Expires header during call setup.

If the refresh message fails (because a firewall blocks it, the network path has changed, or the PBX doesn't handle re-INVITEs correctly), the session timer expires and the call is terminated. The dropout interval will match the Session-Expires value, which is commonly 1800 seconds (30 minutes) but can be configured to other values; RFC 4028 only sets a floor of 90 seconds on the negotiated interval, so the actual value is whatever the endpoints and proxies agreed on.

To diagnose this, check the SIP headers during call setup for a Session-Expires header. If it's present, note the value. If calls drop at or near that interval, session timer refresh failure is the likely cause. Some PBX platforms allow you to disable session timers or adjust the interval. If your calls are otherwise stable, disabling session timers eliminates this as a cause (though it removes the stale session detection benefit).

**[NAT timeout](/blog/sip-nat-traversal)** is the other common cause of calls dropping at consistent intervals. Your router's NAT device maintains a table of active connections. For UDP traffic (which VoIP uses), this table has a timeout, typically between 30 seconds and several minutes. If no traffic passes through a specific NAT mapping within the timeout period, the mapping is removed.

During a normal VoIP call, RTP audio packets flow constantly in both directions, which keeps the NAT mapping alive. But if the call is on hold (where RTP might stop in one or both directions), or if there's a long pause in conversation (and silence suppression is enabled, stopping RTP transmission during silence), the NAT mapping might expire. When audio resumes, the NAT device no longer has a mapping for the returning packets, and the call breaks.

This can also affect the SIP signaling itself. If the SIP session uses keep alive packets to maintain the NAT mapping and those keep alives stop for some reason, the signaling path can break, causing the call to drop.

The fix for NAT timeout issues is to ensure that keep alive intervals are shorter than the NAT device's timeout. Most phones and PBX systems have a keep alive or registration renewal setting. Set it to a value shorter than your router's UDP timeout (which you can usually find in the router's NAT or firewall settings).

## Calls dropping randomly

Random drops without a consistent interval are harder to diagnose because there's no timer pointing you to a specific cause. The most common reasons for random drops are:

**Internet connection instability.** If your internet connection experiences brief outages, even for a few seconds, active VoIP calls may drop. A cable connection that loses sync with the headend for three seconds might not affect your web browsing (the browser just retries), but a phone call experiences three seconds of complete audio loss, and depending on the SIP configuration, the call may be terminated.

Check your modem's logs for sync errors, T3 timeouts (on cable modems), or line errors. These indicate physical layer problems with your connection that cause brief interruptions. If you find frequent errors, contact your ISP. The connection might look fine on a speed test but still have stability issues that affect real time traffic. Running a [VoIP quality test](/tools/voip-test) during the hours when drops occur will surface the packet loss and jitter spikes a speed test hides.

**PBX overload.** If your PBX (whether on premises or cloud hosted) is under heavy load, it might fail to process keep alive messages, re-INVITEs, or other maintenance traffic for active calls. When this traffic is missed, calls can be terminated. Check the PBX's CPU and memory usage during the times when drops are occurring. If the PBX is consistently above 80% CPU, it may be struggling to handle the call volume.

**Routing changes.** If your internet connection or the path between you and your VoIP provider changes mid-call (due to a routing update, a failover event, or an ISP maintenance activity), active calls can be disrupted. This is outside your control but worth knowing about. If drops correlate with your ISP's maintenance window, that's a likely explanation.

**Power issues.** VoIP phones are typically powered by PoE (Power over Ethernet) from the network switch. If the switch's PoE budget is maxed out, phones can lose power intermittently. A switch that's providing PoE to 24 phones and also powering several access points might run out of power budget, causing phones to briefly lose power and drop their calls. Check the switch's PoE utilization.

## Calls dropping when transferred

If calls drop specifically during or immediately after a transfer, the issue is usually with how the transfer is being handled at the SIP level rather than a network problem. Transfers involve a complex sequence of SIP messages (REFER, NOTIFY, a new INVITE to the transfer target), and interoperability issues between different phone brands or PBX platforms can cause transfers to fail.

If transfers consistently fail between specific devices or platforms, check for firmware updates on the phones involved and look for known interoperability notes between the PBX and the phone manufacturer. Some PBX platforms have specific settings for transfer handling that may need to be adjusted for certain phone models.

## Calls dropping during hold

If calls drop specifically when placed on hold or when taken off hold, the issue is usually related to the re-INVITE that the phone sends to signal the hold. The hold operation changes the media session, which requires a re-INVITE with modified SDP. If the re-INVITE fails (blocked by a firewall, rejected by the other end, or mangled by a SIP ALG), the hold operation fails and the call may drop.

Check whether the re-INVITE is being sent and received correctly by examining the SIP debug logs. If the phone sends a re-INVITE for hold and never gets a 200 OK back, the re-INVITE isn't reaching the other end or is being rejected.

## What to document when reporting dropped calls

When you're reporting dropped calls to your VoIP provider or your IT team, the following information dramatically speeds up diagnosis:

The exact time the call dropped. Down to the minute if possible. This allows the support team to find the specific call in their logs.

The direction of the call. Was it inbound or outbound? To what number?

How long the call lasted before dropping. "About 30 seconds" is very different from "about 15 minutes" is very different from "random."

Was the call active, on hold, or being transferred when it dropped?

Does it happen on all phones or just specific ones?

Does it happen at specific times of day?

Has anything changed recently? New router, new ISP, firmware update, new phones added?

Each piece of information eliminates possibilities and narrows the investigation. A dropped call report that says "calls keep dropping" gives the support team almost nothing to work with. A report that says "outbound calls to external numbers drop at exactly 30 seconds, started happening Tuesday after we replaced the router" gives them everything they need.

*Next up: [Echo on VoIP Calls](/blog/echo-on-voip-calls), the different types of echo, what causes each one, and how to fix them.*

---

### Part 4: Echo on VoIP Calls

URL: https://voiptest.com/blog/echo-on-voip-calls
Published: 2026-04-22
Tags: voip-troubleshooting, echo, acoustic-echo, speakerphone, call-quality

*When Your Phones Sound Bad: Part 4 of 12*

Echo on a phone call is exactly what it sounds like: you speak, and a fraction of a second later you hear your own voice coming back at you. It's distracting, disorienting, and makes it difficult to have a natural conversation. The person experiencing the echo hears their own voice delayed. The person causing the echo usually doesn't notice anything wrong on their end, which makes troubleshooting a conversation that requires cooperation from both sides.

Echo on VoIP calls comes from a few different sources, and knowing which type you're dealing with is the key to fixing it.

## Acoustic echo (the most common type)

Acoustic echo happens when sound from a phone's speaker is picked up by the same phone's microphone and sent back to the caller. This is a physical audio problem, not a network problem.

Speakerphones are the most frequent source of acoustic echo. The speaker outputs audio into the room, and the microphone picks up that audio along with the local speaker's voice. Even though modern speakerphones have echo cancellation algorithms built in, these algorithms aren't perfect. They work by detecting audio that the speaker just played and subtracting it from the microphone input. But room acoustics, reflections off hard surfaces, and the volume level all affect how well this works.

If the person you're talking to reports hearing an echo, the problem is almost certainly on your end (your audio is going out your speaker and coming back through your microphone). If you hear an echo of your own voice, the problem is on the far end.

### Fixing acoustic echo

**Switch from speakerphone to handset or headset.** A handset presses the speaker against your ear, which prevents the sound from reaching the microphone. A headset does the same thing. This is the simplest and most effective fix for acoustic echo.

**Reduce the speaker volume.** If speakerphone use is necessary, lowering the volume reduces the amount of audio that the microphone picks up. The echo cancellation algorithm has an easier job when the speaker output is lower.

**Move away from reflective surfaces.** Hard surfaces like glass walls, bare desks, and monitors reflect sound back toward the microphone. Sitting in a room with soft surfaces (carpet, curtains, acoustic panels) reduces reflections and helps the echo canceller do its job.

**Check for defective equipment.** A phone with a deteriorating speaker or a microphone that's become overly sensitive can produce echo that wasn't there before. If echo starts suddenly on a phone that's been working fine, the hardware may be failing.

**Update phone firmware.** Phone manufacturers regularly improve their echo cancellation algorithms in firmware updates. If you're running old firmware, updating may resolve or reduce echo.

## Network echo (less common but trickier)

Network echo is caused by signal reflections in the network path rather than in the room. It's most commonly associated with calls that cross between VoIP and the traditional telephone network, specifically at the point where digital audio is converted to and from analog.

The traditional phone network uses a technology called a hybrid to convert between the four wire circuit used inside the telephone system and the two wire circuit that runs to your handset. This conversion is never perfect. A small amount of the audio signal gets reflected back at the hybrid, creating an echo. On traditional phone calls, this echo exists but the round trip delay is so short (a few milliseconds) that your brain doesn't perceive it as a separate sound.

VoIP changes the equation because it introduces additional delay. The audio has to be encoded, packetized, sent across the network, received, buffered, and decoded. This adds tens of milliseconds to the round trip time. When the echo from the hybrid is combined with this longer delay, the echo becomes perceptible.

Carrier grade gateways that bridge VoIP and the PSTN include echo cancellation hardware specifically designed to handle this. When echo cancellation is working properly, the gateway detects the reflected signal and removes it before it travels back to the VoIP caller. When it's not working properly, you hear your own voice coming back with a noticeable delay.

If you're experiencing echo that only happens on calls to landlines or mobile numbers (not on internal VoIP to VoIP calls), the echo is likely originating at the gateway between VoIP and the PSTN. This is typically your [SIP trunk](/blog/sip-trunking) provider's equipment or the far end carrier's equipment, and the fix is on their side. Report the issue to your trunk provider with specific call examples (dates, times, numbers dialed) so they can examine the relevant gateway's echo cancellation settings.

## Latency amplified echo

Even small amounts of echo that would normally be imperceptible can become noticeable when [latency increases](/blog/latency-jitter-packet-loss-details). A round trip delay of 20 milliseconds makes a tiny echo invisible. A round trip delay of 200 milliseconds makes that same tiny echo sound like a distinct repetition of your words.

This is why echo problems sometimes appear only on calls to distant locations, calls that route through multiple network hops, or calls during periods when network congestion is increasing latency. The echo was always there, but the latency made it audible.

If echo appears only under specific conditions (certain routes, certain times of day, certain endpoints), check the latency on those call paths. Higher latency doesn't cause echo, but it makes existing echo audible. This interaction between delay and echo perceptibility is exactly what the ITU-T G.107 E-model captures: the same echo level costs more conversational quality as round-trip delay grows. Reducing latency (by improving the network path) or eliminating the echo source (by fixing the acoustic or hybrid issue) both work.

## Echo on headsets

Headsets can cause echo in a few ways. Poorly fitting earpieces that don't seal well against the ear allow audio to leak out and reach the microphone. Bluetooth headsets with processing delays can create a feedback loop if their echo cancellation isn't handling the timing correctly. USB headsets with driver issues on the computer can route audio incorrectly.

If echo appears after switching to a new headset, the headset is the likely cause. Try a different headset to confirm. Wired headsets generally produce fewer echo issues than Bluetooth because they have less processing delay. Over ear headsets generally produce fewer issues than earbuds because they provide better acoustic isolation between the speaker and microphone.

## Echo that comes and goes

Intermittent echo is often caused by the far end switching between handset and speakerphone during the call. When they're on the handset, no echo. When they switch to speakerphone, echo appears. If you notice echo starting and stopping during a conversation, ask the other party whether they're switching how they're using their phone.

Intermittent echo can also be caused by the echo cancellation algorithm adapting and losing its calibration. Echo cancellers continuously adjust to the acoustic environment. A sudden change, like someone opening a door, moving to a different position, or bumping the phone, can temporarily confuse the algorithm. The echo appears briefly until the canceller readapts. If this happens frequently, the echo canceller may be marginal for the acoustic conditions in the room.

## Conference calls and echo

Conference calls are particularly susceptible to echo because there are more audio paths, more speakerphones, and more opportunities for audio from one participant's speaker to be picked up by another participant's microphone. A conference room with a speakerphone that doesn't have adequate echo cancellation can create echo for everyone else on the call while the people in the room hear nothing wrong.

The best conference call setup for echo prevention uses a quality conference phone with built in echo cancellation (Polycom/Poly and Yealink make well regarded conference phones), positioned away from reflective surfaces, in a room with some acoustic treatment. Alternatively, having each participant use their own headset eliminates the speakerphone problem entirely, though it changes the dynamics of an in person meeting.

## Diagnosing which end has the problem

The general rule is: the echo is generated at the far end from the person hearing it. If you hear your own voice echoed back, the audio is leaking from speaker to microphone (or reflecting at a hybrid) on the other end of the call. If the other person reports hearing echo, the problem is on your end.

This means that fixing echo requires cooperation from the end that's causing it, which isn't always the end that's complaining about it. If your customers are hearing echo when they call your office, the source is your phones, even though your staff might not notice any issue on their side.

Ask the people who hear the echo to note which calls it happens on. Is it every call? Only speakerphone calls? Only calls to external numbers? Only calls to a specific office or location? The pattern reveals the source.

Be realistic about what a packet capture can prove here. A capture shows you the RTP streams, but echo lives in the audio those streams carry: to implicate a specific endpoint you generally need to decode the audio and check whether the returning stream contains a delayed copy of what the near end sent, and how long that delay is. Pair that with controlled tests: have the suspect end switch from speakerphone to handset mid-call, swap the phone or headset, or place the same call from a different device. When the echo tracks the device rather than the route, you've found your acoustic source.

One more variable worth checking is latency. Echo that would be imperceptible at 20 ms of delay becomes obvious and disruptive at 200 ms, because your own voice comes back after you have finished speaking instead of blending into it. A [VoIP quality test](/tools/voip-test) measures the round-trip latency on your connection -- if it is high, even mild acoustic leakage on the far end will be far more noticeable.

*Next up: [Calls Going Straight to Voicemail](/blog/calls-going-to-voicemail), why the phone doesn't ring and where the call is going instead.*

---

### Part 5: Calls Going Straight to Voicemail

URL: https://voiptest.com/blog/calls-going-to-voicemail
Published: 2026-04-23
Tags: voip-troubleshooting, voicemail, registration, dnd, call-routing

*When Your Phones Sound Bad: Part 5 of 12*

The phone doesn't ring. The caller either gets sent to voicemail immediately or hears a message that the person they're calling is unavailable. The phone is sitting right there on the desk, it looks like it's working, and nobody understands why calls aren't coming through.

This is a different category of problem from audio quality issues. The call isn't happening at all, or it's being redirected before the phone ever has a chance to ring. The causes are usually configuration or connectivity related rather than network quality related, and most of them are straightforward to identify once you know where to look.

## Check 1: Is the phone registered?

This is the most common cause of calls going straight to voicemail, and it should be the first thing you check every time.

A VoIP phone has to [register](/blog/sip-registration) with the phone system (PBX or cloud provider) to tell the system where it is on the network. If the phone isn't registered, the system doesn't know how to reach it. When a call comes in for that extension, the system sees that the phone is unreachable and routes the call to voicemail or plays an unavailable message.

Most phones display their registration status on the screen. Look for messages like "No Service," "Not Registered," "Registration Failed," or a missing extension number on the display. Some phones show a small icon or status indicator. If the phone shows any sign that it's not registered, that's your answer.

Common reasons for registration failure:

**Wrong credentials.** The username, password, or server address configured on the phone is incorrect. This happens after a password change on the PBX that wasn't updated on the phone, after a phone is factory reset, or after an initial provisioning error.

**Network connectivity.** The phone can't reach the registration server. This could be a disconnected Ethernet cable, a switch port that's down, a VLAN misconfiguration, or a DNS resolution failure (the phone is configured with a hostname for the server but can't resolve it to an IP address).

**Firewall blocking.** A firewall between the phone and the registration server is blocking the SIP registration messages. This is common when phones are at remote locations or behind routers with restrictive firewall rules.

**[NAT timeout](/blog/sip-nat-traversal).** The phone registered successfully, but the NAT mapping on the router expired between registration renewals. The system still thinks the phone is registered (the registration hasn't expired yet), but it can't actually reach the phone. This is the sneaky version of this problem because everything looks correct on both sides, but calls still don't arrive. The phone's registration log might show successful registrations, and the server might show the phone as registered, but the network path is broken.

To fix NAT timeout issues, reduce the registration interval on the phone to a value shorter than the router's NAT timeout. A registration interval of 60 seconds usually works for most NAT devices. You can also enable SIP keep alives (often called OPTIONS ping or CRLF keep alive) on the phone, which send periodic small packets to maintain the NAT mapping between registrations.

## Check 2: Do Not Disturb

This one catches people more often than you'd expect. Do Not Disturb (DND) is a feature on most VoIP phones that silently rejects all incoming calls. When DND is enabled, the phone tells the system it's unavailable, and the system routes the call to voicemail.

DND is usually activated by a button on the phone or a soft key on the display. Some phones activate DND with a single accidental button press, and the user doesn't realize it happened. The DND indicator might be a small icon on the screen that's easy to overlook.

Check the phone's display for a DND indicator. Try toggling DND off (the button or soft key should deactivate it) and test an incoming call. If that resolves it, the fix is awareness. If accidental DND activation is a recurring problem, some PBX platforms allow administrators to disable the DND feature on specific phones or to require a confirmation step before activating it.

## Check 3: Call forwarding

Similar to DND, call forwarding might be active without the user realizing it. If call forwarding is configured to send all calls to an external number or directly to voicemail, the desk phone won't ring.

Check the phone's forwarding settings and check the PBX configuration for that extension. Call forwarding can be set at the phone level (the phone itself redirects calls before they ring) or at the PBX level (the PBX redirects calls before sending them to the phone). Both need to be checked.

Some PBX platforms have a "find me/follow me" feature that routes calls to a series of numbers in sequence. If this is misconfigured, calls might be sent to the wrong destination before the desk phone has a chance to ring.

## Check 4: Ring group or queue configuration

If the phone is supposed to receive calls through a ring group, hunt group, or call queue, the configuration of that group determines which phones ring and in what order. A phone that's been accidentally removed from the group, or a group whose ring strategy has been changed (from "ring all" to "round robin," for example), can result in certain phones not ringing for calls they used to receive.

Check the ring group or queue configuration on the PBX. Verify that the affected extension is a member of the correct groups and that the ring strategy matches what's expected.

## Check 5: Time based routing

Many PBX systems have time conditions that route calls differently based on the time of day, day of week, or holiday schedule. If calls go to voicemail only at certain times, check the time conditions in the PBX configuration. A common issue is a time condition with the wrong timezone set, causing business hours routing to kick in at the wrong times. Another common issue is a holiday schedule that hasn't been updated and is still active past the actual holiday.

## Check 6: DNS resolution

If phones are configured to connect to the PBX or VoIP provider using a domain name (like `sip.provider.com`) rather than a direct IP address, DNS resolution failure will prevent registration. The phone can't translate the domain name to an IP address, so it can't send registration messages, so it can't receive calls.

DNS issues can be intermittent. If your DNS server is slow or occasionally unresponsive, phones might register successfully most of the time but fail during periods when DNS is flaky. This creates an intermittent pattern where calls sometimes go to voicemail and sometimes ring normally.

Check the phone's configured DNS server. Try manually resolving the PBX hostname from a computer on the same network to verify DNS is working. If the phone's DHCP assigned DNS server is the router itself, try pointing it to a reliable external DNS server instead, to rule out router DNS issues.

## Check 7: The phone is ringing but the user doesn't hear it

Sometimes the phone is actually ringing but the user doesn't notice. This sounds silly, but it's worth checking. The ring volume might be turned down to zero. The ringer might be muted (some phones have a physical ringer switch on the bottom or side). The phone might be configured with a custom ringtone that isn't playing correctly.

Pick up the phone's handset during a test call to see if the call is actually arriving at the phone. If you can answer the call, the phone is receiving it but the ringer isn't alerting the user.

## Check 8: Inbound routing from the SIP trunk

If no phones in the office are ringing for external calls, but internal calls (extension to extension) work fine, the problem is likely in the inbound trunk routing. The [SIP trunk](/blog/sip-trunking) delivers incoming calls to the PBX, and the PBX needs to know what to do with them based on the dialed number (the DID).

If the DID mapping is missing or incorrect, the PBX receives the incoming call but doesn't know which extension to route it to. Depending on the configuration, it might send the call to a default destination (which might be voicemail), play a "number not in service" message, or simply reject the call.

Check the PBX's inbound routing rules. Verify that each DID number is mapped to the correct extension, ring group, or auto attendant. If the trunk provider recently changed their configuration (moved to new equipment, changed the format of the calling/called numbers), the DID format in the incoming SIP message might not match what your PBX is expecting.

## The pattern tells the story

The most useful diagnostic step for calls going to voicemail is identifying the pattern. Does it happen to all phones or just one? All calls or just external calls? All the time or just certain times? Every answer eliminates possibilities.

One phone affected: probably phone registration, DND, or forwarding on that specific phone. All phones affected: probably PBX configuration, trunk routing, or a network issue between the phones and the PBX. Only external calls: trunk routing or trunk registration. Only at certain times: time conditions or NAT timeout. Intermittent: NAT timeout, DNS issues, or network instability.

---

*Next up: [Caller ID Not Showing or Showing the Wrong Number](/blog/caller-id-problems), explaining why the display says "Unknown" or shows a number you don't recognize.*

---

### Part 6: Caller ID Not Showing or Showing the Wrong Number

URL: https://voiptest.com/blog/caller-id-problems
Published: 2026-04-24
Tags: voip-troubleshooting, caller-id, cnam, stir-shaken, sip-trunking

*When Your Phones Sound Bad: Part 6 of 12*

Caller ID problems come in several flavors. Your outbound caller ID shows the wrong number to the people you call. Your outbound calls show "Unknown" or "Private" when they shouldn't. Inbound calls display just a number with no name. Inbound calls show "Anonymous" even though the caller didn't intend to block their ID. Each of these has different causes and different fixes.

Caller ID on VoIP is more complicated than most people realize because the identity information travels through multiple systems, each of which can modify or override it. Your phone sets one value, your PBX may change it, your SIP trunk provider may override it again, and the receiving carrier may look it up in a different database entirely. Understanding this chain is the key to figuring out where the problem is.

## How caller ID works on VoIP calls

When your phone system places an outbound call through a SIP trunk, the caller ID information is carried in the [SIP message headers](/blog/anatomy-of-a-sip-message). There are multiple headers that can contain identity information, and different systems look at different headers:

The **From header** contains a display name and a SIP address. This is what your PBX typically sets when it originates the call.

The **P-Asserted-Identity header** is added by a trusted intermediary (usually the SIP trunk provider or an SBC) to assert the verified identity of the caller. Many carriers use this header for caller ID display rather than the From header.

The **Remote-Party-ID header** is an older mechanism that serves a similar purpose to P-Asserted-Identity. Some systems still use it.

The challenge is that different carriers and different endpoints look at different headers. Your PBX might set the correct number in the From header, but your trunk provider might ignore From and only use P-Asserted-Identity. If the trunk provider is overriding P-Asserted-Identity with the main trunk number rather than the specific extension's direct line, your outbound caller ID will show the wrong number.

## Outbound caller ID shows the wrong number

This is the most common caller ID complaint. You have multiple phone numbers (a main line and several direct lines), and when employees call out, the caller ID shows the main number instead of their direct line, or shows a number that doesn't belong to anyone.

The issue is almost always in how your PBX or trunk provider is handling the outbound caller ID. Here's where to check:

**PBX outbound caller ID settings.** Most PBX platforms let you configure the outbound caller ID at the trunk level, the extension level, or both. If the trunk level caller ID is set to the main number and the extension level isn't overriding it, every outbound call shows the main number. Check the PBX configuration for both the trunk and the individual extensions.

**Trunk provider caller ID policy.** If you are not sure which carrier owns the number showing up on outbound calls, a [carrier lookup](/tools/carrier-lookup) can identify the owning carrier and line type. Some [SIP trunk](/blog/sip-trunking) providers override whatever caller ID your PBX sends and replace it with the number registered on your trunk account. This is partly a fraud prevention measure (preventing you from spoofing numbers you don't own) and partly how their system works. Contact your trunk provider and ask how they handle outbound caller ID. Many providers allow you to add multiple numbers to your account's "authorized caller ID" list, so you can send any of your assigned numbers as the outbound ID.

**Number format.** If your PBX sends the caller ID in a format the trunk provider doesn't recognize (for example, sending a 7 digit local number when the provider expects a full 10 or 11 digit number with country code), the provider may default to the trunk's main number. Check that the number format in your PBX matches what the provider expects.

## Outbound calls show "Unknown" or "Private"

If your calls display as "Unknown" or "Private" to the people you're calling, one of two things is happening. Either your PBX is intentionally sending a privacy indicator in the SIP headers (which tells the receiving carrier to hide the caller ID), or your PBX isn't sending caller ID at all and the receiving carrier is interpreting the absence as intentional privacy.

Check the SIP headers your PBX is sending. If there's a Privacy header set to "id" or "full," that's explicitly requesting caller ID suppression. If the From header contains "anonymous" as the user portion, that also signals privacy.

If privacy isn't intentionally enabled, check that the From header and P-Asserted-Identity header both contain a valid phone number. An empty or malformed caller ID field might be interpreted by the receiving carrier as a blocked number.

Also check with your trunk provider. Some providers strip caller ID from calls if the number you're trying to send isn't in their list of numbers authorized for your account. This is a STIR/SHAKEN consideration (the authentication framework designed to combat caller ID spoofing). If you're sending a caller ID number that doesn't belong to your trunk, the provider might remove it rather than allow an unverified number through.

## Inbound calls show number but no name

You receive a call, and the phone displays the calling number but no name, even though you know the caller's name should be available. This is a CNAM (Caller Name) lookup issue.

How the caller's name reaches your phone depends on the call path. For calls that originate on SIP-native networks, the display name is carried in the SIP headers (the From header and P-Asserted-Identity header) and can travel end-to-end from the originating system to your phone. In these cases, a CNAM database lookup isn't needed because the name is already in the signaling.

The situation is different for calls that originate from the traditional PSTN or TDM network. The legacy SS7/ISUP signaling used on those networks carries the calling number but not the calling name. When these calls are handed off to a SIP carrier, the name field is empty. To fill it in, your carrier (or your PBX, if configured to do so) performs a CNAM database lookup using the calling number. If the number isn't in the CNAM database, if the lookup fails, or if nobody in the chain is performing the lookup, you see only the number.

In practice, many calls pass through a mix of SIP and TDM segments, and the name can be lost at any PSTN gateway along the way. This is why CNAM lookups remain important even in a predominantly SIP world.

This is different from internal calls, where the name is carried directly in the SIP From header and displayed by the phone without any database lookup.

If you're consistently not seeing caller names on inbound external calls, check whether your VoIP provider performs CNAM lookups. Some providers include this in their service, others charge extra for it, and some don't offer it at all. If your PBX is capable of doing CNAM lookups directly (some platforms support this through third party CNAM lookup services), that's another option.

Keep in mind that CNAM databases aren't always accurate or complete. The caller's carrier is responsible for submitting the name to the database, and not all carriers keep their records current. Cell phone numbers are particularly inconsistent in CNAM databases. There's only so much you can do about inaccurate or missing entries in external databases.

## Inbound calls show "Anonymous"

When an inbound call displays "Anonymous," "Blocked," or "Restricted," it usually means the calling party intentionally blocked their caller ID. Their phone or carrier is sending a privacy indicator in the SIP headers, and your carrier is honoring it by not displaying the number.

In some cases, the privacy isn't intentional. The caller's PBX might be misconfigured, sending privacy headers by default when nobody asked for it. Or a trunk provider in the chain might be stripping caller ID as a policy for certain call types.

You generally can't override a legitimate privacy request. The caller has the right to block their number, and the telephone system is designed to honor that. If you're receiving an unusually high number of anonymous calls that you believe should have caller ID, the callers' PBX may be misconfigured and they may not be aware their number is being blocked. Letting them know can help them fix it on their end.

## STIR/SHAKEN and attestation

STIR/SHAKEN is a framework implemented by US carriers to combat caller ID spoofing. When a call is placed, the originating carrier attaches a digital certificate that attests to the legitimacy of the caller ID. There are three attestation levels:

**Full attestation (A)** means the carrier has verified that the caller is authorized to use the displayed number. This is the highest level of trust.

**Partial attestation (B)** means the carrier has verified the caller's identity but can't confirm they're authorized to use the specific number.

**Gateway attestation (C)** means the call entered the carrier's network from an international gateway or other source where the origin can't be fully verified.

Calls with full attestation are less likely to be flagged as spam or blocked by the receiving carrier. Calls with lower attestation or no attestation may be marked as "Spam Likely" or "Scam Likely" on the recipient's phone, or may even be blocked entirely.

If your outbound calls are being marked as spam or aren't being answered, check with your SIP trunk provider about your STIR/SHAKEN attestation level. Ensuring that your caller ID numbers are properly registered with your provider and that your provider is signing calls with full attestation can improve your call completion rate and prevent your legitimate business calls from being flagged. Keep your expectations realistic, though. Attestation verifies identity, not intent, which is a big part of [why caller ID still lies in 2026](/blog/stir-shaken-reality-2026) even with the framework fully deployed.

## The systematic approach

For outbound caller ID issues: check PBX extension settings, then PBX trunk settings, then the trunk provider's caller ID policy and authorized number list. For inbound caller ID issues: check whether your provider does CNAM lookups and whether the issue is specific to certain callers (their problem) or all callers (your provider's configuration). For calls being flagged as spam: check STIR/SHAKEN attestation with your trunk provider.

---

*Next up: [Audio Delay and Talking Over Each Other](/blog/audio-delay-talking-over), for when the conversation feels like it's happening on a satellite phone from the 1990s.*

---

### Part 7: Audio Delay and Talking Over Each Other

URL: https://voiptest.com/blog/audio-delay-talking-over
Published: 2026-04-25
Tags: voip-troubleshooting, latency, delay, audio-delay, call-quality

*When Your Phones Sound Bad: Part 7 of 12*

The conversation feels wrong. You say something, and there's a noticeable pause before the other person responds. Or worse, you both start talking at the same time because neither of you can tell when the other has finished speaking. The audio isn't choppy, it isn't cutting out, and the call is clear. It's just delayed, like watching a video that's slightly out of sync.

This is a latency problem, and while it's one of the simpler VoIP issues to understand conceptually, it can be one of the harder ones to fix because the cause often lives somewhere outside your direct control.

## What latency means for a phone call

[Latency](/blog/latency-jitter-packet-loss-details) is the time it takes for data to travel from one point to another. On a VoIP call, latency is the delay between the moment you speak and the moment the other person hears it. Some amount of latency is unavoidable. The audio has to be captured by the microphone, encoded into digital data, packetized, transmitted across the network, received, decoded, and played through the speaker. Even under ideal conditions, this takes a few milliseconds.

The question is how much latency before it becomes a problem. The most commonly cited figures come from ITU-T G.114, the transmission-planning recommendation for one-way delay, and it's worth being clear that these are [planning targets, not points where audio suddenly fails](https://www.itu.int/rec/T-REC-G.107/en). The conversational effect depends on the total mouth-to-ear delay and on how well echo is controlled, but the tiers hold up well as a working guide:

Under 150 milliseconds one way: the conversation feels natural. Most people notice essentially no delay at all. This is [the planning boundary G.114 cites for most applications](https://www.itu.int/rec/T-REC-G.114/en), not a cliff on either side of it.

150 to 400 milliseconds one way: the delay becomes noticeable. Conversations still work but feel slightly unnatural, and you might occasionally talk over each other. G.114 describes this band as acceptable provided planners are aware of the impact.

Over 400 milliseconds one way: G.114 puts this beyond the ceiling for general network planning. The delay is significant and makes fluid conversation difficult. Both parties frequently talk over each other, and there are long uncomfortable pauses as each person waits to make sure the other has finished speaking.

For reference, a phone call between two VoIP phones on the same local network might have 5 to 20 milliseconds of latency. A call between two offices in the same city over a good internet connection might have 20 to 50 milliseconds. A call from the US to Europe might have 80 to 120 milliseconds just from the physical distance the data has to travel. A call over a geostationary satellite connection has 600 or more milliseconds, as discussed in the [Getting the Internet Right series](/blog/satellite-internet).

## Where latency comes from

Latency is cumulative. Every component in the path between your mouth and the other person's ear adds some delay. The total latency is the sum of all these contributions.

**Encoding delay.** The codec that encodes your voice into digital data takes time to process. G.711 has minimal encoding delay because it's a simple encoding. G.729 has slightly more because it uses compression. Opus can vary depending on its configuration. The encoding delay is typically 5 to 40 milliseconds and is not usually the primary culprit.

**Packetization delay.** Audio is collected into packets covering a fixed time interval ([usually 20 milliseconds](https://www.rfc-editor.org/rfc/rfc3551.html)). The phone has to wait for a full packet's worth of audio before it can send anything. This adds 20 milliseconds of delay by definition.

**Network delay.** The time for the packet to travel from your phone to the other person's phone. This includes the time to traverse your local network, your internet connection, the internet backbone (potentially crossing multiple networks), the other party's internet connection, and their local network. Network delay varies based on geographic distance, the number of routing hops, congestion levels, and the type of connections involved.

**Jitter buffer delay.** The receiving phone uses a jitter buffer to smooth out variations in packet arrival times. The buffer holds packets for a short period to allow late packets to arrive before playing them in sequence. A larger jitter buffer adds more delay but handles jitter better. A smaller buffer adds less delay but is more sensitive to timing variations. The jitter buffer typically adds 20 to 80 milliseconds.

**Processing delay.** The PBX, SBC, or any other intermediary that processes the call adds a small amount of delay. If the PBX is transcoding (converting the audio from one codec to another), the transcoding process adds additional delay, potentially 20 to 40 milliseconds per transcoding step.

## Diagnosing latency

The first step is measuring it. Running our [VoIP quality test](/tools/voip-test) will show you the latency your connection adds under realistic voice traffic conditions. For a quick check, the simplest approach is a ping test to a relevant destination. Ping your VoIP provider's SIP server or a point as close to the other end of the call as possible. The round trip time (RTT) in the ping response gives you the network portion of the latency. Divide the RTT by two for the approximate one way network delay. It is approximate because internet paths are often asymmetric in both route and queuing, so the two directions can differ more than halving suggests.

If the ping RTT to your VoIP provider is 40 milliseconds, that's about 20 milliseconds one way network delay. Add the encoding, packetization, and jitter buffer delays (collectively maybe 40 to 60 milliseconds on each end), and the total one way latency is roughly 100 to 120 milliseconds. That's fine. If the ping RTT is 200 milliseconds, the total one way latency is probably around 160 to 180 milliseconds, which is getting into the range where the delay becomes noticeable.

If you have access to your PBX or VoIP provider's call detail records, many systems report RTP statistics including round trip time for each call. This gives you a direct measurement rather than the approximation from a ping test.

## Common causes of excessive latency

**Geographic distance.** Data travels through fiber at roughly 200,000 km/s (about two-thirds the speed of light in vacuum), but over thousands of miles that still adds up. A call from New York to London (approximately 5,570 km great-circle distance) adds about 28 milliseconds each way from propagation alone, and lands nearer 35 to 45 milliseconds each way in practice once the real cable route and the router hops along it are counted. You can't fix physics. If you're making a lot of international calls and latency is an issue, the only mitigation is ensuring everything else in the chain is as fast as possible so you're not adding avoidable delay on top of the unavoidable distance.

**Too many network hops.** Every router between you and the destination adds a small amount of processing delay. If your traffic is taking an inefficient path through the internet (routing through multiple ISPs, going through a distant exchange point rather than a local one), the accumulated delay can be significant. A traceroute to your VoIP provider's server shows you the path and the delay at each hop. If you see a large jump in latency at a specific hop, that hop is the bottleneck.

**ISP congestion.** When your ISP's network is congested, packets wait in queues at congested points, which adds delay. This is the same congestion that causes choppy audio, but at lower levels of congestion the effect is increased latency rather than packet loss. Latency that's worse during peak hours (midday, early evening) and better during off peak hours is a classic congestion pattern.

**VPN routing.** If your VoIP traffic is routed through a VPN, the VPN adds delay in several ways. The traffic has to be encrypted and encapsulated, which takes processing time. The traffic may travel to a VPN concentrator that's geographically distant from the direct path, adding physical distance. And the VPN endpoint may be on a congested network. If you're experiencing latency on calls and using a VPN, test with the VPN disconnected to see if the latency drops.

**Transcoding.** If your PBX is converting between codecs (for example, your phone uses Opus internally and the SIP trunk uses G.711), each transcoding step adds delay. If the call is being transcoded on both the inbound and outbound legs, the delay adds up. Minimizing transcoding by using the same codec end to end, or at least ensuring only one transcoding step occurs, reduces latency.

**Oversized jitter buffer.** If the jitter buffer on the phone is set to a large fixed value, it adds unnecessary delay even when network conditions are good. Most modern phones use an adaptive jitter buffer that adjusts its size based on actual network conditions. If your phone allows you to configure the jitter buffer, set it to adaptive (or dynamic) rather than a large fixed value.

## What you can control and what you can't

Some sources of latency are within your control: your local network, your [QoS configuration](/blog/quality-of-service-explained), your codec selection, your jitter buffer settings, your VPN routing, and whether your PBX is transcoding. These are all things you can optimize.

Some sources are partially within your control: your ISP (you can choose a provider with a better network, or upgrade to a connection with lower latency), your VoIP provider (some providers have better network peering than others, which affects latency to different destinations).

Some sources are outside your control: geographic distance, the routing decisions of upstream ISPs, and congestion on networks you don't operate. For these, the best you can do is ensure that everything within your control is optimized so you're not adding avoidable delay to the unavoidable baseline.

If latency is consistently high on calls to specific destinations, it's worth asking your VoIP provider whether they have a point of presence closer to those destinations, or whether their peering with the relevant carriers could be improved. Good VoIP providers invest in network peering specifically to reduce latency on voice traffic.

---

*Next up: [Phones Not Ringing for Incoming Calls](/blog/phones-not-ringing), covering what to check when the call arrives but the phone stays silent.*

---

### Part 8: Phones Not Ringing for Incoming Calls

URL: https://voiptest.com/blog/phones-not-ringing
Published: 2026-04-26
Tags: voip-troubleshooting, phones-not-ringing, ring-group, call-routing, inbound-calls

*When Your Phones Sound Bad: Part 8 of 12*

This problem overlaps with the [calls going to voicemail](/blog/calls-going-to-voicemail) post, but there's an important distinction. In that post, we covered situations where the call is being diverted before it reaches the phone (registration failure, DND, forwarding, routing issues). This post covers the scenario where the call appears to be reaching the phone but the phone doesn't ring, or where specific phones in a group should ring but don't.

The phone is sitting on the desk. It's powered on. It looks registered. But when someone calls, it stays silent while other phones in the office ring, or no phones ring at all.

## The phone is registered but not ringing

If the phone shows as registered and appears to be connected, but incoming calls don't make it ring, there are several things to check.

**Ring volume.** This seems obvious, but it's a real issue. Most VoIP phones have a ring volume control, and it can be turned all the way down without the phone showing any obvious indication that it's muted. Some phones have a physical ringer switch (often on the bottom or back of the phone) that silently disables the ringer.

Pick up the handset and have someone call the extension. If you hear the call coming through on the handset, the phone is receiving the call and the ringer is the issue. Turn the ring volume up or check for a ringer mute switch.

**Ringtone file.** If the phone is configured to use a custom ringtone file and that file is missing, corrupted, or in a format the phone can't play, the phone might fail silently. It receives the call notification but can't play the associated sound. Some phones fall back to a default tone in this situation. Others just stay silent.

Try resetting the ringtone to the phone's default tone and test. If the default tone works, the custom ringtone file was the problem.

**Phone firmware bug.** Certain firmware versions on certain phone models have known bugs where the ringer stops working under specific conditions. This might happen after the phone has been running for a long time without a reboot, after a call with specific SIP characteristics, or after a specific sequence of events on the phone. Rebooting the phone resolves it temporarily, and updating the firmware usually fixes it permanently.

If the problem is intermittent and a reboot always fixes it, firmware is the likely cause. Check the manufacturer's release notes for known issues related to ringing.

## Hunt groups and ring groups

If the phone is part of a ring group or hunt group and isn't ringing when the group is called, the issue might be in the group configuration rather than the phone itself.

**Ring strategy.** Ring groups have different strategies: ring all (every phone in the group rings simultaneously), round robin (phones ring one at a time in sequence), linear (phones ring in a fixed order), and others. If the strategy is round robin or linear and the affected phone isn't early in the sequence, it might not ring if someone answers before the group rotates to that phone. Verify that the ring strategy matches what you expect.

**Member status.** Some PBX platforms allow ring group members to log in and out of the group. An agent who logged out of the group (intentionally or accidentally) won't receive calls for that group even though their phone is working fine for direct calls. Check the group's member status and ensure the affected phone is logged in.

**Ring timeout.** The ring time per member in a hunt group determines how long each phone rings before the group moves to the next member. If the timeout is too short, the phone might ring so briefly that the user doesn't notice before the call moves on. Increase the ring time per member to a reasonable value (15 to 25 seconds is common).

**Penalty or priority settings.** Some queue and ring group implementations have penalty or priority settings that determine which phones ring first. A phone with a high penalty value might only ring after all lower penalty phones have been tried. Check these settings if the affected phone is in a queue.

## Internal calls work but external calls don't ring

If calls between extensions ring fine but calls from outside don't ring, the problem is between the SIP trunk and the PBX's internal routing.

**Inbound route configuration.** The PBX needs to know what to do with an incoming call based on the dialed number (DID). If the inbound route for a specific DID is misconfigured, pointing to the wrong extension or missing entirely, that DID's calls won't reach the intended phone. Check the inbound routing rules on the PBX.

**Trunk registration.** If the [SIP trunk](/blog/sip-trunking) uses registration authentication and the registration has failed, external calls can't arrive at all. Check the trunk's registration status on the PBX. If it shows as unregistered or failed, troubleshoot the trunk connection (credentials, network, firewall) before looking at individual phone issues.

**DID format mismatch.** SIP trunk providers send the dialed number in a specific format. Some send the full number with country code (+15551234567). Others send just the 10 digit number (5551234567). Others send just the last 4 digits. If your PBX's inbound routing rules expect one format and the trunk delivers another, the PBX can't match the incoming call to a route and the call fails or goes to a default destination.

Check the PBX logs to see exactly what DID format is arriving from the trunk, and ensure your inbound routing rules match that format.

## SIP forking and multiple devices

Many VoIP setups allow a single extension to ring on multiple devices simultaneously: a desk phone, a softphone on a computer, and a mobile app. This is called SIP forking, where the PBX sends the incoming call notification to every registered device for that extension.

If one device rings but another doesn't, the non-ringing device might have a registration issue, a network issue, or a configuration difference. Check that all devices for the extension are properly registered and that the PBX is configured to fork calls to all of them.

Some PBX platforms have a "max contacts" setting that limits how many devices can register with the same extension. If you have three devices but the limit is set to two, the third device either can't register or pushes one of the others off. Check the max contacts setting.

## Call notification timing

VoIP phones rely on [SIP INVITE](/blog/first-call-flow-invite-to-bye) messages to know that a call is coming in. If there's a delay between the PBX sending the INVITE and the phone receiving it, the phone starts ringing late. If the delay is long enough, the call might have already been answered by another phone in a ring group, or the caller might have hung up before the phone starts ringing.

This delay can come from network latency, DNS resolution delays, or the phone processing the incoming INVITE slowly (which can happen on older or lower powered hardware). If a phone consistently starts ringing a few seconds after the other phones in a group, it has a processing or connectivity disadvantage that should be investigated.

## VLANs and network segmentation

If phones are on a separate VLAN from the PBX (which is a recommended configuration for QoS purposes), routing between the VLANs needs to work correctly. A misconfigured VLAN, a missing route between VLANs, or a firewall between the voice and data VLANs can block the SIP INVITE from reaching the phone.

This is a common issue after network changes. A switch reconfiguration, a new firewall rule, or a VLAN change can inadvertently break the path between the PBX and the phones. If phones stop ringing after a network change, check the routing and firewall rules between the relevant VLANs.

## When nothing rings at all

If no phones in the office ring for any calls, the problem is almost certainly at the PBX or trunk level rather than individual phone level. Check the PBX itself: is it running? Is it reachable on the network? Is the SIP trunk registered and active? Are there error messages in the PBX logs?

A PBX that's running but overloaded might fail to process incoming calls. A PBX with a full disk might stop writing logs and eventually stop processing calls. A PBX with a certificate expiration might fail TLS connections to the trunk provider. These are system level issues that affect all calls, not just specific phones.

If the PBX checks out, look at the network path between the outside world and the PBX. A firewall rule change, an ISP outage affecting only certain ports, or a DNS change that broke the trunk provider's ability to reach your PBX can all cause a complete inbound call failure.

---

*Next up: [Call Quality Is Fine in the Morning But Bad in the Afternoon](/blog/afternoon-call-quality), exploring the daily pattern that points to a specific set of causes.*

---

### Part 9: Call Quality Is Fine in the Morning But Bad in the Afternoon

URL: https://voiptest.com/blog/afternoon-call-quality
Published: 2026-04-27
Tags: voip-troubleshooting, bandwidth, congestion, qos, call-quality

*When Your Phones Sound Bad: Part 9 of 12*

This pattern is one of the more telling clues in VoIP troubleshooting. Calls are clear and crisp first thing in the morning. By midday, they start getting choppy. By 2 or 3 PM, the quality is noticeably worse. By the end of the business day, things are bad enough that people are complaining. The next morning, everything is fine again.

The daily cycle tells you that the problem is related to usage. Something that isn't happening in the morning is happening in the afternoon, and it's degrading the conditions that voice traffic needs to sound good. The question is what, and whether it's inside your network or outside of it.

## The most likely cause: bandwidth saturation

When call quality degrades as the day gets busier, the most common explanation is that your internet connection's available bandwidth is being consumed by everything your office is doing, and voice traffic is suffering because it's competing for space.

In the morning, usage is light. A few people are checking email, someone loads a webpage. Your 50 Mbps upload can handle this easily, and the voice traffic has plenty of room. By early afternoon, more people are active. Someone starts a video conference. The cloud backup kicks in. A few people are uploading files to a shared drive. The marketing team is uploading video content to social media. Now that 50 Mbps upload is being asked to carry a lot more, and voice packets are waiting behind larger data transfers.

Upload is the direction that matters most here. As covered in the [Getting the Internet Right series](/blog/how-internet-connections-work), your upload bandwidth is typically much smaller than your download bandwidth on cable and most shared fiber connections. Voice calls need consistent upload bandwidth for the outgoing audio. When the upload is saturated, voice packets get delayed or dropped, and you hear choppy or degraded audio.

### How to confirm this

Run a speed test during the morning when calls sound fine. Note the upload speed. Run the same test during the afternoon when calls sound bad. If the afternoon upload speed is significantly lower than the morning speed, your upload bandwidth is being consumed. Running a [VoIP quality test](/tools/voip-test) during both windows is even more telling, because it measures jitter and packet loss alongside throughput, which a basic speed test does not.

Better yet, if your router supports bandwidth monitoring, look at the real time upload utilization during the problem periods. If upload utilization is consistently at or near the connection's maximum during the times when calls are bad, you've found the cause.

### How to fix it

**[QoS configuration](/blog/quality-of-service-explained).** Configure Quality of Service on your router to prioritize voice traffic. When QoS is active, the router ensures voice packets are sent first, even when the connection is busy. Other traffic gets slightly delayed to make room for voice, which is the right tradeoff because a web page loading 100 milliseconds slower is invisible to the user, while a voice packet arriving 100 milliseconds late is audible. One caveat on scope: QoS on your router controls only your side of the link: it decides which packets enter your upload queue first, but it cannot fix congestion inside the ISP's network, and DSCP markings (the EF marking RFC 4594 recommends for telephony media) may be ignored or remarked once traffic leaves your network.

**Identify and schedule heavy traffic.** Cloud backups, large file syncs, software updates, and other bandwidth intensive operations should be scheduled for off hours if possible. Most backup and sync applications have scheduling features. Moving these to evening or overnight hours frees up bandwidth during business hours.

**Upgrade the connection.** If QoS and scheduling aren't sufficient, the connection itself may need to be upgraded. This might mean a faster plan from the same provider (if one with better upload is available), switching from cable to fiber (for better upload speeds), or adding a dedicated connection for voice traffic.

## ISP congestion

If your own bandwidth isn't the issue (your speed tests show full capacity even during the afternoon), the congestion might be on your ISP's network. As covered in the [cable internet post](/blog/cable-internet), shared internet connections like cable share bandwidth among all customers connected to the same node. When more customers in your area are active during the afternoon, the shared capacity gets divided among more users, and your effective bandwidth drops even though nothing on your end has changed.

ISP congestion shows up as reduced speed test results during peak hours, increased latency on ping tests, and sometimes increased [jitter](/blog/what-is-jitter-and-why-it-matters) and packet loss. If you're consistently seeing degraded metrics during business hours but full performance early in the morning or late at night, ISP congestion becomes a plausible explanation, but treat it as a hypothesis to verify, not a conclusion. A degraded afternoon speed test can just as easily reflect your own concurrent traffic. Test from a machine plugged directly into the modem (or with the office LAN quiesced), collect time-stamped results across several days, and check your router's utilization graphs for the same windows. Only when your own upload is demonstrably idle during the bad periods does the evidence point at the provider.

This is harder to fix because it's not under your control, but the dated evidence you gathered is what makes the report actionable; ISPs move faster on documented patterns than on general complaints. You can report the issue to your ISP and ask about node capacity. ISPs do split overloaded nodes periodically, but it's on their timeline. If the congestion is persistent, switching to a less congested ISP (if options exist at your address), upgrading to a dedicated connection that isn't shared, or adding a separate dedicated connection for voice are the most effective long term solutions.

## Internal network congestion

Sometimes the congestion isn't on the internet connection at all. It's on the internal network. This happens when your internal switches or access points are oversubscribed during busy periods.

A common scenario: a 100 Mbps switch port connects to a device that's doing large file transfers to a local server. The same switch is handling phone traffic. During heavy file transfer periods, the switch's backplane or a specific uplink port gets congested, and voice packets experience delay.

This is more common with older or cheap switches that don't handle traffic prioritization well. Managed switches with VLAN support and QoS solve this by putting voice traffic on a separate VLAN with priority handling. If your phones and computers are on the same unmanaged switch, upgrading the switching infrastructure can eliminate internally generated congestion.

## Video conferencing load

The rise of video conferencing has created a new bandwidth pressure that wasn't there a few years ago. A single video call can consume 2 to 4 Mbps of upload bandwidth. An office with five people on simultaneous video calls could be using 10 to 20 Mbps of upload just for video, which on a connection with 20 to 30 Mbps total upload leaves very little room for voice and everything else.

If the afternoon quality degradation correlates with periods of heavy video conferencing use, the video traffic is likely the competing demand. QoS can help by ensuring voice gets priority over video when both are competing. Reducing video resolution settings on conferencing platforms also helps. Most platforms allow administrators to set default bandwidth limits for video calls.

## The pattern as the diagnosis

The daily pattern itself is the most useful diagnostic information. If someone reports "call quality is bad," that's hard to investigate. If someone reports "call quality is bad between 1 and 4 PM every weekday," that's almost certainly a congestion issue and the question is just whether the congestion is on the internet connection, at the ISP level, or on the internal network.

Document the pattern. Note the times when quality is good and when it's bad. Correlate with activities in the office (meeting schedules, backup schedules, video conferencing patterns). Run a [VoIP quality test](/tools/voip-test) during both good and bad periods. The comparison between good and bad periods will point you directly at the cause.

---

*Next up: [Calls Sound Fine Internally But Bad on External Calls](/blog/internal-vs-external-calls), which covers what to check when internal calls are clear but external calls degrade.*

---

### Part 10: Calls Sound Fine Internally But Bad on External Calls

URL: https://voiptest.com/blog/internal-vs-external-calls
Published: 2026-04-28
Tags: voip-troubleshooting, external-calls, sip-trunk, transcoding, call-quality

*When Your Phones Sound Bad: Part 10 of 12*

Everything sounds great when you call a coworker across the office. Crystal clear audio, no delay, no choppiness. But when you call a customer, a vendor, or anyone outside the office, the audio quality drops noticeably. The difference might be subtle or dramatic, but it's consistent: internal good, external bad.

This is actually one of the more useful symptoms because it narrows the fault domain considerably, though narrows is the right word, not pinpoints. If internal calls are fine, your local network is healthy for at least one media path. But the comparison doesn't clear every component: codec negotiation (SDP offer/answer, RFC 3264) runs per call and per leg, so internal and external calls often use different codecs, and depending on configuration the internal media may flow phone-to-phone without ever touching the PBX, while trunk calls are anchored through it. What the symptom really tells you is to focus on everything that differs between the two paths: the trunk leg, the codec negotiated on it, where the media is anchored, and your internet connection.

## Why internal and external calls are different

When you call another extension in your office, the audio typically stays entirely on your local network. The RTP packets carrying your voice travel from your phone to the PBX (or directly to the other phone, depending on the configuration) over your internal switches and cables. The audio never touches the internet. The round trip path might be a few hundred feet of Ethernet cable.

When you call an external number, the audio has to leave your building. It travels over your internet connection, through your ISP's network, across the internet to your SIP trunk provider, through their infrastructure, and then across the telephone network to the destination. The round trip path might cross thousands of miles and dozens of network devices.

Every additional component in that path is an opportunity for [latency, jitter, and packet loss](/blog/latency-jitter-packet-loss-details) to be introduced. Internal calls have almost none of those components. External calls have all of them.

## The SIP trunk connection

The [SIP trunk](/blog/sip-trunking) is the bridge between your phone system and the outside world. If external call quality is consistently bad, the trunk connection is the first place to investigate.

**[Codec mismatch](/blog/sdp-media-negotiation) or transcoding.** Internal calls between your phones probably use whatever codec your phones negotiate directly, which might be Opus, G.722, or G.711 depending on your configuration. The SIP trunk might require a different codec, commonly G.711 for PSTN interconnection. If the codec on the trunk doesn't match the codec used internally, your PBX has to transcode, converting the audio from one format to another in real time.

Transcoding adds processing delay and can reduce audio quality, particularly if the PBX is transcoding under heavy load. Check whether your internal phones and your trunk are using the same codec. If not, consider configuring them to match. G.711 is the safest universal choice because it's supported by virtually every SIP endpoint and trunk provider, and it avoids transcoding entirely if used end to end.

If transcoding is unavoidable (your phones use a wideband codec like Opus or G.722 for better internal audio quality, and the trunk requires G.711), at least ensure that only one transcoding step occurs. If both legs are being transcoded (internal phone to PBX, then PBX to trunk), the double transcoding compounds the quality loss.

**Trunk provider quality.** Not all SIP trunk providers are equal in terms of audio quality. Some providers invest heavily in their network infrastructure, maintaining well peered connections with low latency to the major carriers. Others route traffic through cheaper paths that add latency and are more susceptible to quality issues.

If you've ruled out other causes and external call quality is consistently mediocre, it might be worth testing a different trunk provider. Many providers offer trial periods or pay per use pricing that lets you compare quality without a long term commitment. When evaluating, pay attention to latency to the provider's servers (a ping test gives you a rough idea), and ask about their network peering and the path your calls take to reach the major carriers.

**Trunk capacity and congestion.** If your SIP trunk has a limited number of concurrent channels and those channels are fully utilized, additional calls might be routed through a secondary path that has worse quality, or calls might fail entirely. Even if the trunk isn't at capacity, the provider's infrastructure might be congested during peak hours.

Check your trunk's concurrent call usage during the times when quality is worst. If you're consistently near the channel limit, you may need more capacity.

## Your internet connection (upload specifically)

External calls use your internet connection's upload bandwidth to send outgoing audio. Internal calls don't use the internet at all. So if your upload is constrained, only external calls are affected.

This is the same bandwidth saturation issue covered in the [afternoon call quality post](/blog/afternoon-call-quality), but framed differently. The key test: run a speed test and a ping test to your trunk provider's server during a period when external calls sound bad. If the speed test shows reduced upload, or the ping test shows elevated latency or packet loss, your internet connection is the constraint.

QoS configuration on your router specifically prioritizes the VoIP traffic going to and from your trunk provider's IP addresses. This ensures that voice gets through even when other traffic is competing for the upload.

## Firewall and router processing

Your firewall or router might be introducing latency or dropping packets on traffic that crosses the network boundary. This affects external calls (which cross the firewall) but not internal calls (which stay within the LAN).

If your firewall is performing deep packet inspection, intrusion detection, content filtering, or other CPU intensive operations on outbound traffic, these processes can add milliseconds of delay to every packet. Under heavy load, the firewall might even drop packets that it can't process quickly enough.

Check the firewall's CPU utilization during problem periods. If it's consistently high, the firewall might be a bottleneck. Some firewalls allow you to create rules that bypass deep inspection for specific traffic types or destinations. Exempting your trunk provider's IP addresses from intensive inspection can reduce the delay on voice traffic.

## The far end

Sometimes the problem isn't on your end or on your trunk's end. It's on the far end of the call. If external calls to certain numbers or carriers sound bad but calls to others sound fine, the issue might be with the destination carrier's network, the called party's phone system, or the interconnection between your trunk provider and the destination carrier.

This is largely outside your control, but it's worth identifying because it prevents you from chasing a problem on your own infrastructure that doesn't exist there. If the quality issue is specific to calls to a particular area code, carrier, or destination, report it to your trunk provider with specific examples. They can investigate the routing path to that destination and potentially adjust their routing to use a better path.

## Testing methodology

To systematically determine where external call quality is degrading:

1. Test an internal call. If it sounds fine, your local network is healthy for that path, but remember internal calls may use a different codec and may flow phone-to-phone without touching the PBX, so this narrows the search rather than clearing the PBX outright.
2. Run a ping test to your trunk provider's SIP server. Note the latency and packet loss.
3. Place a test call to an external number and note the quality.
4. Check your PBX logs for the call to see what codec was negotiated on the internal leg and the trunk leg. If they're different, transcoding is happening.
5. Run a speed test during the external call. Note the upload speed and compare to your plan's rated speed.
6. Check your firewall's CPU and connection table utilization.

Each test eliminates a possible cause. If the ping test shows good metrics but external calls sound bad, the problem is likely in the codec negotiation, transcoding, or the trunk provider's network beyond their SIP server. If the ping test shows poor metrics, the problem is your internet connection or your ISP.

---

*Next up: [Static, Buzzing, or Humming on Calls](/blog/static-buzzing-humming), which covers the electrical and hardware problems that create persistent background noise.*

---

### Part 11: Static, Buzzing, or Humming on Calls

URL: https://voiptest.com/blog/static-buzzing-humming
Published: 2026-04-29
Tags: voip-troubleshooting, static, buzzing, hardware, poe, electrical-interference

*When Your Phones Sound Bad: Part 11 of 12*

Static, buzzing, or a persistent hum on phone calls is a different kind of problem from the packet loss and jitter issues that cause choppy or robotic audio. Where choppiness comes from network conditions, static and buzzing usually come from the analog parts of the path: the handset or headset, a power supply, an ATA or analog wiring, or the gateway's interface to the phone network. The audio isn't cutting out or breaking up. There's a constant unwanted noise layered over (or underneath) the conversation.

The character of the noise is actually diagnostic. A steady hum at a consistent pitch is different from random crackling, which is different from a buzz that fluctuates. Each type points to different causes.

## Steady hum or drone

A constant hum, especially one at a low pitch, is almost always a ground loop or electrical interference issue.

**Ground loops.** A ground loop occurs when there are multiple paths to electrical ground in a system, creating a loop that acts like an antenna for hum. In a VoIP context, this almost always involves analog interconnects: an analog phone adapter (ATA) connected to both the network and an analog phone with its own grounding, a headset amplifier or external speaker with its own power supply, or analog trunk wiring at a gateway. It is rarely the Ethernet side. Ethernet ports are transformer-isolated, and PoE rides on those same isolated magnetics, so the data connection itself does not normally complete a ground loop. Treat "PoE ground loop" as a last-resort diagnosis that needs actual electrical evidence, not a starting assumption.

The classic test for a ground loop is to disconnect everything from the phone except the Ethernet cable and see if the hum goes away. Then reconnect devices one at a time. When the hum returns, you've found the device creating the loop.

If the hum is on a phone connected to an ATA (an adapter that connects a traditional analog phone to a VoIP system), the analog phone or the wiring between the ATA and the phone is the likely source. Analog phone connections are susceptible to electromagnetic pickup from nearby power cables, fluorescent lights, and other electrical equipment. Moving the ATA and its wiring away from power sources, or replacing the analog phone with an IP phone that doesn't need the ATA, often resolves the issue.

**Power supply noise.** If the phone is powered by an external power adapter rather than PoE, a failing or low quality power adapter can introduce electrical noise into the phone's audio circuitry. Try a different power adapter of the same rating. If the hum goes away, the original adapter was the culprit.

**Electromagnetic interference (EMI).** Phones placed near transformers, uninterruptible power supplies (UPS), fluorescent lighting ballasts, or large electrical equipment can pick up electromagnetic interference. This is more common with analog connections (ATAs and analog phones) than with digital IP phones, but even IP phones can be affected if the interference is strong enough to affect the phone's audio processing hardware.

Try moving the phone to a different location, at least a few feet from the suspected source of interference. If the hum stops or changes significantly, EMI is the cause.

## Random crackling or static

Crackling and static that come and go, especially in bursts, are typically caused by an intermittent physical connection. The first question is which side of the phone the fault sits on. True analog crackle, the continuous frying texture layered under the voice, points at the analog parts: a handset cord, a headset connector, a failing speaker, or the phone-side wiring of an ATA. Faults on the Ethernet side sound different. A bad cable or port corrupts and drops packets, and the phone's packet loss concealment renders that as clicks, brief gaps, or robotic-sounding audio rather than continuous static, and the loss is visible in the stream's RTCP statistics (RFC 3550) and in a [VoIP quality test](/tools/voip-test). Keep that distinction in mind as you work through the checks below.

**Bad Ethernet cable.** A damaged Ethernet cable causes errors at the physical layer that drop frames; on a call, that manifests as the clicks, gaps, and garbled passages just described rather than analog-style static. The cable might have a damaged connector, a kink, an internal break in one of the wire pairs, or water damage. These problems can be intermittent, appearing when the cable is moved or when temperature changes cause expansion and contraction.

Replace the Ethernet cable between the phone and the switch. Use a known good cable and see if the crackling stops. If the phone connects through a wall jack, test by running a temporary cable directly from the switch to the phone, bypassing the wall jack and the in wall cabling. If the direct cable works, the problem is in the wall cabling or the jack.

**Failing switch port.** A switch port with a failing transceiver can cause link errors and packet loss that appear as dropouts and clicks. If replacing the cable doesn't help, try moving the phone's cable to a different port on the switch. If the artifacts stop, the original port may be faulty.

**[PoE](/blog/your-local-network) issues.** If the phone is powered by PoE and the switch's PoE delivery is unstable (due to a failing PoE controller, an overloaded PoE budget, or a cable that's marginal for PoE delivery), the phone can experience power fluctuations. Those typically show up as link flaps, reboots, or brief dropouts; only in marginal cases does the phone's own power or audio circuitry turn them into audible noise. Check the switch's PoE utilization and the power consumption of the affected port.

Standard 802.3af (PoE) and 802.3at (PoE+) can deliver power over just two of the four pairs in an Ethernet cable, which is sufficient for most VoIP phones. However, the specific PoE mode matters. "Mode A" PoE delivers power over the data pairs (pairs used for 10/100 Ethernet), while "Mode B" PoE delivers power over the spare pairs that 10/100 Ethernet does not use for data. If your switch uses Mode B and a spare pair is damaged, PoE will fail even though data works fine on the two data pairs. Only 802.3bt (PoE++, Type 3 and Type 4) requires all four pairs, but that standard is uncommon for typical VoIP phones. In practice, a cable that works for data at 100 Mbps (which only needs two pairs) can still fail for PoE if the pairs used for power delivery are damaged. This is a common gotcha with older cabling where unused pairs were never tested.

## Buzzing that changes or fluctuates

A buzz that fluctuates in intensity, comes and goes, or changes character when you move the phone or touch a cable is almost always an intermittent contact point, and which cable reacts tells you which domain the fault is in. If the buzz responds to the handset or headset cord, an ATA's phone-side wiring, or an external audio accessory, it's an analog contact problem. If it seems to track the Ethernet cable, remember that the transport there is digital: an intermittent data contact produces dropouts and clicks, not a shifting buzz, so a buzz that follows the Ethernet cable usually points at the phone's own jack or power path rather than the data signal.

Check the physical connections on both sides. Reseat every connector. Check for corrosion on contacts, especially in environments with high humidity. Look for cables that are bent sharply at connector points or run across areas where they get stepped on or pinched by furniture.

In [older buildings](/blog/new-building-infrastructure), cabling might be run near or through the same conduit as electrical wiring, and it's worth being precise about what that can and cannot do to a call. Audio crosses an Ethernet cable as digital packets, so induced 50/60 Hz noise doesn't bleed into the conversation as hum the way it does on an analog pair; what strong interference can do, especially on damaged or poorly terminated cable, is corrupt frames, which surfaces as packet loss and dropouts. Analog runs are the opposite: an ATA-to-phone pair routed alongside power wiring will happily pick up audible hum. Rerouting cable away from power lines, replacing damaged runs, or using shielded cable where the environment demands it helps in both cases.

## Noise on all calls versus specific phones

If every phone in the office has the same noise issue, look for a shared element in the audio path rather than reaching for a network-wide grounding theory: the trunk gateway, the PBX or a shared media resource, or the provider's side of the calls. Because Ethernet ports are transformer-isolated, a building-wide ground loop propagating over the data network is an unlikely diagnosis without measurable electrical evidence of a wiring fault. If the noise is present even on internal phone-to-phone calls, suspect the PBX or media server; if it appears only on external calls, suspect the gateway or trunk (see below).

If only one phone has the noise, the problem is specific to that phone, its cable, its switch port, or its immediate environment. The troubleshooting approach is to isolate: swap the phone with a known good phone to determine if the noise follows the phone (hardware issue) or stays at the location (cable, port, or environmental issue).

## Noise on external calls only

If noise appears only on calls to external numbers (especially to landlines), the issue might be at the gateway between VoIP and the PSTN. The gateway converts between digital VoIP audio and the analog or digital signals of the traditional phone network. A poorly configured gateway, a failing line card, or an issue on the PSTN side of the gateway can introduce noise into the audio path.

This is typically on the [trunk provider's](/blog/sip-trunking) side and needs to be reported to them with specific call examples. If the noise is only on calls to a specific number or area, the issue might be on the far end carrier's network rather than your trunk provider's.

## Noise from the phone hardware

Phones contain speakers and microphones that can develop issues over time. A phone with a speaker that's developing a fault might produce crackling or distortion. A phone with debris in the microphone port might produce a muffled buzz when the user speaks. A phone with a loose component might produce intermittent noise when the phone is bumped.

If the noise is consistent across all calls on a specific phone and you've ruled out cable, switch port, and environmental causes, the phone itself might be failing. Test with a different phone at the same location. If the noise goes away with the replacement phone, the original phone needs to be replaced.

## Headset noise

If the noise is only present when a user is on a headset and not when using the handset, the headset is the issue. Wireless headsets, particularly Bluetooth, can introduce noise from interference with other wireless devices. Wired headsets with a damaged cord or a loose connector can produce crackling. USB headsets with driver issues can produce buzzing.

Test with a different headset. If the noise goes away, the original headset is the problem. For wireless headsets, moving the base station away from other wireless devices (WiFi access points, Bluetooth devices) can reduce interference.

---

*Next up: [Fax Over IP: Why Faxing Over VoIP Is Unreliable and What to Do About It](/blog/fax-over-ip), the one use case that VoIP was never designed for.*

---

### Part 12: Fax Over IP: Why Faxing Over VoIP Is Unreliable and What to Do About It

URL: https://voiptest.com/blog/fax-over-ip
Published: 2026-04-30
Tags: voip-troubleshooting, fax, t38, fax-over-ip, ata

*When Your Phones Sound Bad: Part 12 of 12*

Every other post in this series has been about voice calls. This one is about faxing, which might seem out of place in a VoIP troubleshooting guide, but it's here for a good reason: fax problems are one of the most common complaints from businesses that have moved to VoIP. The phones work fine. The fax machine doesn't. It drops pages, fails to connect, sends garbled documents, or just refuses to work at all.

The frustrating part is that this isn't really a bug. Fax machines were designed for a specific kind of network, and VoIP is a fundamentally different kind of network. Understanding why faxing struggles on VoIP explains the problem and, more importantly, helps you pick the right solution.

## Why fax and VoIP don't mix

Traditional fax machines communicate by sending modulated audio tones over a phone line. One machine calls the other, they negotiate a speed and encoding using a series of handshake tones, and then the sending machine converts the document into audio signals that the receiving machine decodes back into an image. The entire process relies on the audio connection being clean, consistent, and uninterrupted.

On a traditional phone line (POTS, Plain Old Telephone Service), this works well because the audio path is a dedicated circuit with predictable, consistent characteristics. The signal goes in one end and comes out the other end essentially unchanged.

VoIP doesn't work this way. VoIP takes audio, encodes it with a codec, breaks it into packets, sends those packets across the internet, and reassembles them at the other end. This process introduces several things that fax machines can't tolerate.

**Compression.** Most voice codecs are lossy, meaning they discard audio information that humans won't notice to reduce bandwidth. G.729, Opus, and other compressed codecs do this aggressively. The audio sounds fine to a human ear because the discarded information falls outside the range that matters for speech comprehension. But a fax machine isn't listening to speech. It's listening to precise tonal signals, and the information that the codec discarded might include critical parts of those signals. A compressed codec can make fax tones unrecognizable to the receiving machine.

**Jitter.** Fax machines expect tones to arrive at precise, consistent intervals. Network jitter disturbs that timing, and an adaptive jitter buffer, the kind voice calls want, makes it worse for fax, because every mid-call resize shifts the timing of the played-out audio. For voice this is fine; human ears tolerate small timing variations. For fax, those shifts can cause the receiving machine to misinterpret the signals. The remedy is not to remove the jitter buffer but to pin it: fax-optimized device profiles (Cisco's fax guidance for the ATA 191/192, for example) switch to a fixed jitter buffer for fax calls so playout timing stays constant.

**Packet loss.** Even a tiny amount of packet loss, which would be barely noticeable on a voice call, can corrupt a fax transmission. A lost packet means a gap in the tone sequence, which the receiving fax machine may interpret as a different signal, a transmission error, or a disconnect command. Human ears fill in small gaps in speech automatically. Fax machines don't.

**Echo cancellation.** VoIP systems typically run echo cancellation on the audio path to prevent voice echo. Echo cancellers can interfere with fax tones because they may treat the fax signals as echo and try to remove them. Most VoIP systems are supposed to disable echo cancellation when they detect fax tones, but this detection doesn't always work reliably.

## G.711 passthrough: the minimum viable approach

The simplest approach to faxing over VoIP is to ensure that the fax connection uses G.711 (either PCMU or PCMA) without any compression, echo cancellation, or silence suppression. G.711 is an uncompressed codec that passes audio through without modification. If the fax tones go in one end as G.711 and come out the other end as G.711, with no transcoding in between, the tones arrive essentially unchanged.

For this to work, every component in the path between the two fax machines needs to pass G.711 without modification. Your PBX needs to use G.711 on the ATA port connected to the fax machine. Your SIP trunk needs to use G.711 for the fax call. No transcoding can happen anywhere in the chain. Echo cancellation and silence suppression need to be disabled for the fax connection, and the jitter buffer should be set to a fixed size rather than left adaptive. The exact knobs are device- and provider-specific: most ATAs expose a fax-optimized line setting or profile that makes these changes together (Cisco documents them for the ATA 191/192, for example), and your trunk provider may have its own recommended fax configuration, so follow both rather than a generic checklist.

G.711 passthrough works reasonably well under good network conditions. If your internet connection has low latency, low jitter, and minimal packet loss, faxes will often transmit successfully. But "reasonably well" and "reliably" are different things. Even with G.711, the packetization process introduces jitter that traditional fax wasn't designed for, and any network hiccup during the transmission can corrupt or fail the fax.

Many businesses use G.711 passthrough for faxing and find it works well enough most of the time. If your faxing volume is low and the occasional failed fax isn't a serious problem, this approach may be sufficient.

## T.38: the proper solution for fax over IP

T.38 is a protocol specifically designed for fax over IP. Instead of trying to carry fax tones as audio over a voice codec (which is what G.711 passthrough does), T.38 decodes the fax signals at the sending end, converts them into data packets (IFP, Internet Facsimile Protocol packets), sends those packets over the IP network, and then reconstructs the fax signals at the receiving end.

The critical difference is that T.38 sends the fax data as data, not as audio. The tonal signals are decoded into their meaning (image data, handshake commands, timing signals) and transmitted digitally. This eliminates the sensitivity to codec compression, jitter, and the other audio path issues that make fax unreliable on VoIP.

T.38 also includes error correction mechanisms. In its typical deployment over UDPTL (UDP Transport Layer for T.38), it uses forward error correction through redundancy: each UDPTL packet includes copies of previous IFP packets, so if a packet is lost, the data it carried is likely included in a subsequent packet. This is not retransmission in the TCP sense. The sender does not wait for acknowledgment and resend lost packets. Instead, the redundancy is sent proactively so the receiver can reconstruct missing data from later packets. (T.38 can also run over TCP, which would provide true retransmission, but TCP-based T.38 is rarely used in practice.) This redundancy mechanism makes T.38 significantly more reliable than audio passthrough on networks with moderate packet loss.

For T.38 to work, both your side and the remote side of the fax connection need to support it. Specifically:

Your ATA (analog telephone adapter, the device that connects your fax machine to the VoIP network) needs to support T.38. Most modern ATAs do.

Your PBX needs to support T.38 and be configured to use it for fax calls. Asterisk, FreeSWITCH, and most commercial PBX platforms support T.38, but it often needs to be explicitly enabled.

Your [SIP trunk](/blog/sip-trunking) provider needs to support T.38 on their side. Not all providers do, and among those that do, the quality of their T.38 implementation varies. Ask your trunk provider whether they support T.38 and whether there's any additional configuration needed on their end.

When a fax call is placed over a T.38 capable connection, the call typically starts as a normal voice call using G.711. When the system detects fax tones (the initial CNG or CED tones that fax machines exchange), it switches the call from audio mode to T.38 mode. This switchover is called a "T.38 reinvite" because the system sends a [SIP re-INVITE](/blog/sdp-media-negotiation) requesting to change the media type from audio to T.38.

If the switchover fails (because one side doesn't support T.38, or the reinvite is blocked by a firewall or SBC), the call may fall back to G.711 passthrough or may fail entirely, depending on the configuration. Monitoring the SIP reinvites during fax calls is one way to diagnose T.38 issues.

## Fax over email (the practical alternative)

For many businesses, the most reliable solution to fax over VoIP problems is to stop sending fax over VoIP entirely and switch to a fax over email service instead.

Fax over email services (sometimes called electronic fax or internet fax) work by receiving faxes on the provider's infrastructure (which has dedicated, optimized fax connections) and delivering them to you as email attachments, typically PDF files. Outbound faxes are sent by emailing a document to the service, which transmits it from their infrastructure.

The advantages are significant. You don't need a fax machine. You don't need an ATA. You don't need to worry about T.38 support, codec configuration, or network quality affecting fax reliability. The provider handles all the tricky parts on infrastructure designed for faxing, and you interact with faxes as simple email attachments.

Many providers offer fax over email services, some bundled with VoIP phone service and some as standalone products. For businesses that still need to send and receive faxes but are struggling with reliability over their VoIP connection, this is often the most practical solution.

## Keeping a traditional fax line

For businesses with high fax volume or regulatory requirements around faxing (healthcare and legal are the most common), keeping a traditional analog phone line specifically for the fax machine is worth considering. A single POTS line dedicated to faxing eliminates all VoIP related fax issues because the fax traffic never touches the VoIP system.

The cost of a single analog line is modest, typically $20 to $40 per month depending on your area. Compared to the time and frustration of troubleshooting intermittent fax failures over VoIP, a dedicated fax line can be a bargain.

This approach is particularly appropriate when fax reliability is critical, when you transmit long or complex documents (which are more susceptible to errors over VoIP), or when the other parties you fax with regularly are on systems that don't support T.38. One caveat: [AT&T begins decommissioning its copper network in mid-2026](/blog/pots-copper-shutdown-2026), and other carriers have their own retirement timelines, so treat a dedicated analog fax line as a bridge rather than a permanent solution.

## When fax over VoIP fails intermittently

If you're using G.711 passthrough or T.38 and faxes work sometimes but fail other times, the network conditions during the failure periods are almost certainly the cause. Fax is far less tolerant of network imperfections than voice. A level of jitter or packet loss that's completely invisible on a voice call can be enough to fail a fax.

Run network quality tests during the times when faxes are failing. As rules of thumb rather than hard limits (the exact tolerance depends on the modulation speed and whether error correction mode is active) packet loss above 0.1% or jitter above 20 milliseconds during a transmission window is enough to suspect the network as the cause. Improving the network conditions (QoS, bandwidth management, connection upgrade) will help. And expect fax to show the strain early: audio fax passthrough is acutely sensitive to loss, to jitter buffer adjustments, to transcoding and to timing changes, so on the same path it often fails while conversational speech still sounds acceptable. How much margin you actually have depends on the modulation rate in use, whether error correction mode is active, the gateway or ATA implementation, and whether the call runs as [T.38](/blog/how-t38-fax-works) rather than passthrough. So treat fax as an early warning rather than a fixed threshold that breaks before everything else.

Reducing the fax speed can also help. Most ATAs allow you to configure the maximum fax speed. The default is often 14400 bps. Reducing it to 9600 bps gives the fax protocol more time to recover from errors and makes the transmission more tolerant of network imperfections. You'll trade speed for reliability, but most faxes at 9600 bps still complete in a reasonable time.

---

*This is the final post in the When Your Phones Sound Bad series. For foundational VoIP knowledge, the [VoIP From the Ground Up series](/blog/how-does-a-phone-call-actually-work) starts from the basics. For internet connection guidance, the [Getting the Internet Right series](/blog/isp-foundation) covers selecting and evaluating business internet. For protocol level troubleshooting, the [SIP Signaling From the Wire Up series](/blog/what-sip-actually-is) goes deep on the signaling layer.*

---

## Series: Moving Your Office Without Losing Your Mind (or Your Phones)

An 8-part guide to moving your business phone system to a new office. Covers ISP selection, building infrastructure, number porting, overlap periods, move day execution, and post-move verification.

### Part 1: Start With Internet: Pick the ISP Months Before You Move

URL: https://voiptest.com/blog/office-move-start-with-internet
Published: 2026-05-01
Tags: office-move, isp-selection, business-internet, planning

*Moving Your Office Without Losing Your Mind (or Your Phones): Part 1 of 8*

You've found a new office. The lease is signed or close to it. Someone has started a spreadsheet with moving tasks: furniture, keys, cleaning, mail forwarding, all the logistics that come with relocating a business. Somewhere on that list, probably near the bottom, is a line item that says something like "set up internet and phones at new office."

That line item should be at the top. Not because internet is more important than having desks and chairs, but because it has the longest lead time of anything on the list, and if it's not handled early, it will become the thing that delays everything else.

## Why internet takes so long

When you order residential internet, the provider usually shows up within a week. Business internet can work on a similar timeline if you're ordering cable or shared fiber that's already available at the address. But that's the best case.

If the connection type you need isn't already available at your new address, things get slower. [Dedicated fiber (DIA)](/blog/dedicated-internet-access) typically takes 30 to 90 days from order to activation, and that timeline starts after the provider completes a site survey and confirms the order. If construction is required, meaning fiber needs to be physically built to your building or suite, the timeline can extend to 120 days or more depending on permitting, construction scheduling, and weather.

That means if you sign a lease for a new office and start your internet order the same week, you might have dedicated fiber ready by the time you move in. If you wait until a month before the move to start thinking about it, you could be sitting in a beautiful new office with no internet for weeks after move day.

Even for simpler installations like cable or shared fiber, there are potential delays. The provider might need to schedule a technician. The building might need a new cable run from the street to your suite. The building owner might need to grant access for the installation. These things take days to weeks, not hours.

## Check availability before you sign the lease

Ideally, you should check internet availability at a prospective office location before you commit to the lease. Discovering after you've signed a three year lease that the building has no fiber, the only available cable provider has terrible reviews, and the nearest DSL central office is four miles away is a bad surprise that could have been avoided.

Checking availability isn't as simple as searching one provider's website. As covered in the [Getting the Internet Right series](/blog/isp-foundation), the carrier landscape at any given address is fragmented. There might be multiple providers that can serve the address, including regional carriers and competitive providers that don't show up in a basic Google search. The building itself might have an exclusive arrangement with a specific provider, or it might have fiber from a provider you've never heard of that was installed when the building was constructed.

Two buildings on the same street might have completely different connectivity options. The one with better internet infrastructure could save you thousands of dollars per year and prevent the daily frustration that comes with an inadequate connection. Checking with multiple providers, including regional carriers and competitive providers that don't advertise to consumers, gives you the fullest picture of what's available. Don't rely on a single provider's availability checker. The carrier landscape at any given address is more fragmented than most people realize.

## What to order and when

Once you've confirmed availability and chosen a provider, the ordering timeline depends on the connection type.

**Cable or shared fiber:** Order 4 to 6 weeks before your target move date. This gives enough buffer for scheduling, any unexpected building access issues, and a week of testing before the move.

**Dedicated fiber (DIA) where fiber already exists at the building:** Order 60 to 90 days before your target move date. Even when fiber infrastructure is in place, provisioning a new DIA circuit involves site surveys, contract processing, circuit testing, and scheduling the turn-up.

**Dedicated fiber where construction is needed:** Order as early as possible, ideally 90 to 120 days or more before the move. Construction timelines are the least predictable because they depend on permitting from the city, contractor availability, and physical conditions at the site.

**[Fixed wireless](/blog/fixed-wireless):** Order 3 to 4 weeks before the move. Installation requires a site survey (to verify line of sight) and antenna installation, which is faster than running cable but still needs scheduling.

**Cellular backup:** Order 2 to 3 weeks before. Cellular failover devices are typically shipped and self-installed, so the lead time is mostly shipping and account activation.

If you're planning a redundant setup with two connections from different providers (which we recommend for businesses that can't afford extended downtime, as covered in the [redundancy post](/blog/redundancy-failover)), you need to manage both timelines independently. Order the slower one first.

## The overlap period

There's a period during an office move where you need connectivity at both the old location and the new location. Your team is still working at the old office while the new one is being set up. Phones need to work at both locations during the transition. Cloud applications need to be accessible from both.

Plan for at least two to four weeks of overlap where you're paying for internet at both locations. This overlap gives you time to test the new connection, set up phones and equipment at the new location, and resolve any issues before you cut over.

Cutting the old connection too early is one of the most common mistakes in office moves. If the new internet has an installation delay, or if the new connection has problems that weren't caught during initial testing, you need the old connection as a fallback. An extra month of paying for two connections is cheap insurance compared to a week of your entire team being unable to work.

## Test before move day

Once the new connection is installed, test it thoroughly before moving any production equipment or people. Run speed tests at different times of day. Test latency and jitter. Run a [VoIP quality test](/tools/voip-test) to measure whether the new connection can actually support voice traffic, and use a [bandwidth calculator](/tools/bandwidth-calculator) to confirm it has enough headroom for your expected call volume. If possible, set up a phone at the new location and make test calls to verify voice quality. Check both internal connectivity (can devices on the network talk to each other) and external connectivity (is the internet connection performing as expected).

If you're using a managed firewall or router, configure it at the new location and verify that all the rules and settings are working before the move. Discovering a firewall misconfiguration on move day, when everyone is trying to get set up and start working, is a stressful and avoidable problem.

This testing period is also when you'll discover any building specific issues: a flaky cable run from the building entrance to your suite, WiFi interference from neighboring tenants, or an unexpected network configuration requirement from the building's management.

## What to put in the lease

While you're negotiating the lease for the new space, there are several telecom related items worth addressing:

**Access for providers.** Confirm that you have the right to bring in any internet provider of your choosing. Some buildings have exclusive agreements with a single provider, which limits your options and can result in higher prices.

**Pathway access.** Confirm that there's a clear pathway for running cable from the building's point of entry (the demarc, or demarcation point) to your suite. In multi-tenant buildings, this might involve running cable through shared spaces, risers, or conduit that the building owner controls.

**Roof access for wireless.** If you plan to use fixed wireless (either as a primary or backup connection), you may need antenna access on the building's roof or exterior wall. Confirm that the lease allows this and whether there are any restrictions or fees.

**Construction permission.** If fiber needs to be built to the building, confirm that the building owner will permit the construction and won't charge excessive fees for access.

These may seem like minor details during lease negotiations, but they can become major obstacles later if they're not addressed. A building that won't allow you to bring in your preferred ISP, or that charges a $5,000 riser access fee, can significantly change the cost and viability of your connectivity plan.

## The bottom line

Internet and phone connectivity is the longest lead time item in most office moves, and it's the one that everything else depends on. You can't set up cloud workstations without internet. You can't configure phones without the connection they'll run on. You can't test anything without the infrastructure being in place.

Start early, verify availability before committing to a location, order the connection as soon as you know where you're going, build in an overlap period, and test before move day. The businesses that handle office moves smoothly are the ones that treat connectivity as a planning priority rather than an afterthought.

*Next up: [What to Do When the New Building Doesn't Have What You Need](/blog/new-building-infrastructure), on handling the gap between what's available and what your business requires.*

---

### Part 2: What to Do When the New Building Doesn't Have What You Need

URL: https://voiptest.com/blog/new-building-infrastructure
Published: 2026-05-02
Tags: office-move, building-infrastructure, cabling, isp-availability

*Moving Your Office Without Losing Your Mind (or Your Phones): Part 2 of 8*

You checked availability. You found a building you love. But the internet options don't match what your business needs. Maybe the building only has cable and you need dedicated fiber. Maybe the existing cabling inside the building is old Cat3 that won't support modern network speeds. Maybe the only provider available has a terrible reputation in your area. Maybe there's no fiber within a mile of the property.

This is more common than people expect, especially in older buildings, suburban office parks, and areas where infrastructure buildout hasn't kept pace with demand. The good news is that "the building doesn't have what you need today" doesn't necessarily mean "you can't get what you need." It just means there's work to do, and the earlier you start, the more options you have.

## When the right ISP isn't available yet

If the connection type you want isn't available at the address, the first step is finding out how close the nearest infrastructure is. For fiber, this means asking providers how far their nearest fiber is from the building. For fixed wireless, it means determining whether there's a tower with line of sight.

If fiber is within a few hundred feet of the building, the construction cost to extend it might be minimal. Some providers will cover the construction cost entirely if you sign a term contract, absorbing the build cost in exchange for a guaranteed revenue stream. Others will quote a construction charge that might range from a few hundred dollars to tens of thousands depending on the distance and complexity.

The key variables in construction cost are:

**Distance.** More cable in the ground means more cost. Every foot of trenching or conduit adds to the bill.

**Terrain and access.** Running fiber under a parking lot is cheaper than running it under a road with traffic. Aerial construction (on utility poles) is generally cheaper than underground construction but depends on pole availability and access agreements.

**Permitting.** If the construction crosses public right of way, the provider needs permits from the city or county. Permitting timelines vary enormously by jurisdiction, from a few weeks to several months. The provider handles this, but you bear the timeline impact.

**Building entry.** Getting the fiber from the property line into the building and then to your suite involves coordination with the building owner and may require additional interior construction.

If the construction cost is prohibitive, consider alternatives. Fixed wireless might be available if the building has line of sight to a provider's tower. A cellular connection (LTE or 5G) might serve as a primary connection for a small office or as a backup while you wait for better options. In some cases, working with the building owner to bring infrastructure to the building benefits all tenants, and the owner may be willing to share the construction cost or coordinate with a provider on behalf of the building.

## When the building's internal wiring is inadequate

The connection from the street to the building is one piece. The wiring inside the building is another, and it's often the part that gets overlooked.

Older buildings may have Category 3 wiring, which was designed for telephone service and in practice tops out at 10 Mbps Ethernet. (Faster operation over Cat3 was standardized, [IEEE 802.3y put 100 Mb/s on Category 3 cable](https://standards.ieee.org/ieee/802.3y/1083/), but the hardware never took hold, and Cat3 supports neither gigabit Ethernet nor PoE beyond the original low-power 802.3af type; 802.3at and everything after it require Cat5 or better.) Some older buildings have no structured cabling at all, just telephone wiring from decades ago that terminates at random wall plates. Even buildings that were wired for data might have Category 5 cable. Gigabit Ethernet was designed to run over Cat5, [IEEE 802.3ab specifies gigabit Ethernet over Category 5](https://standards.ieee.org/ieee/802.3ab/1086/), but TIA retired Cat5 in favor of Cat5e, which is specified to the same 100 MHz but adds tighter crosstalk requirements that make gigabit more reliable in practice. Cat5 is physically similar to Cat5e and usually carries PoE without trouble, but it is the deprecated spec, which makes it a shaky foundation for a modern network.

For a modern VoIP deployment with [PoE](/blog/your-local-network) phones, you want Category 5e at minimum and Category 6 or 6a ideally. Cat6a supports 10 Gbps Ethernet ([IEEE 802.3an defines 10GBASE-T to 100 m](https://standards.ieee.org/ieee/802.3an/3560/)) and handles PoE reliably at longer distances, which provides headroom for future needs.

If the existing cabling is inadequate, you have a few options:

**Run new cable.** A low voltage cabling contractor can run new Cat6 or Cat6a cable throughout your suite. This involves running cables from a central wiring closet to each desk location, terminating them at wall jacks and a patch panel. The cost depends on the number of runs, the distance, and how difficult the routing is (drop ceilings make it easier, concrete walls make it harder). For a typical office of 15 to 20 desks, expect a few thousand dollars for professional cabling.

**Use the existing cable with limitations.** If the existing cable is Cat5e, it will work for most VoIP deployments at gigabit speeds with PoE. It's not ideal for future proofing, but it's functional. If it's Cat3, it won't support modern Ethernet and needs to be replaced for any VoIP deployment.

**Use wireless.** In spaces where running new cable is impractical (temporary locations, historic buildings with walls you can't open), wireless access points with quality of service configuration can support VoIP phones that have WiFi capability. This is a compromise, not a preferred solution, since [WiFi introduces jitter that wired connections avoid](/blog/wired-vs-wifi-for-voip). But it's an option when cabling isn't feasible.

Before you invest in new cabling, have the existing cable tested by a professional with a cable certifier. A certifier tests each run against the specifications for its category rating and reports pass or fail. Some cables that look old might actually test fine for your needs. Others that look fine might have internal faults. Testing takes the guesswork out of the decision.

## When the building has restrictive policies

Some buildings create unnecessary obstacles for tenants trying to set up communications infrastructure.

**Exclusive provider agreements.** Some buildings have agreements with a single ISP that prevent other providers from serving tenants. This limits your options to whatever that provider offers, at whatever price they set, with no competitive pressure. If you're in this situation, your negotiating leverage is limited. You can sometimes negotiate with the building owner to allow additional providers, especially if other tenants are also requesting alternatives, but this can be a slow process.

**High riser fees.** Some buildings charge providers (or tenants) a fee to access the building's riser, which is the vertical conduit that connects floors. These fees get passed on to you, either directly or through higher installation costs from the provider.

**Restricted roof access.** If you want fixed wireless, you need antenna access. Some buildings prohibit roof mounted equipment, charge significant fees for it, or require lengthy approval processes. Ask about this early if wireless is part of your plan.

The best time to address these issues is during lease negotiation, as covered in the [previous post](/blog/office-move-start-with-internet). Once the lease is signed, your leverage diminishes. If you're already committed to a building with restrictive policies, work with your provider to find creative solutions. Sometimes a provider has an existing presence in the building that the management company isn't aware of. Sometimes an antenna can go on an exterior wall instead of the roof. Sometimes the provider has a relationship with the building owner that can expedite access.

## Making the decision: adapt, wait, or walk away

When the new building's infrastructure doesn't match your needs, you essentially have three choices.

**Adapt your requirements.** Maybe cable internet with a cellular backup will work for now, even though your preference is dedicated fiber. If the business can function on the available options while waiting for better infrastructure, adapting in the short term is a practical choice.

**Wait for infrastructure.** If a provider is building out fiber in the area and expects to reach your building within six months, it might be worth starting with a temporary solution and upgrading when fiber arrives. Ask providers about their buildout timelines. Sometimes the infrastructure you need is coming but just isn't there yet.

**Walk away from the building.** If connectivity is critical to your business and the building can't provide what you need within a reasonable timeframe and budget, the building might not be the right choice. A beautiful office with bad internet is a daily frustration for everyone who works there. It's better to find out before you sign the lease than after.

Knowing what's available at multiple prospective locations, including the providers that don't show up on a basic search, lets you factor connectivity into your location decision alongside rent, commute time, and square footage. Reach out to multiple providers, ask building management what's already in the building, and check with neighboring tenants about their experience. Once a connection is installed, run a [VoIP quality test](/tools/voip-test) to verify it can actually support voice traffic, and use the [bandwidth calculator](/tools/bandwidth-calculator) to confirm the connection has enough capacity for your call volume. The more visibility you have into the carrier landscape at each address, the better your decision will be.

The infrastructure situation at your new building isn't always obvious until you dig into it. Dig early, ask the right questions, and make decisions with full information.

*Next up: [Your Phone Numbers and the Move: What Actually Needs to Happen](/blog/porting-numbers-office-move), covering how to keep your existing phone numbers when you change locations or providers.*

---

### Part 3: Your Phone Numbers and the Move: What Actually Needs to Happen

URL: https://voiptest.com/blog/porting-numbers-office-move
Published: 2026-05-03
Tags: office-move, phone-numbers, hosted-voip, e911, number-porting

*Moving Your Office Without Losing Your Mind (or Your Phones): Part 3 of 8*

Here's the good news that a lot of businesses don't realize until someone tells them: if you're on a hosted VoIP system, moving your phone numbers to a new office is not the ordeal it used to be. In most cases, it's barely a task at all.

This is one of the biggest practical advantages of hosted VoIP over traditional phone service, and it's worth understanding clearly because it eliminates what used to be one of the most stressful parts of any office move.

## If you're on hosted VoIP, your numbers probably just move with you

With a hosted (cloud) VoIP system, your phone numbers don't live at your office. They live with your VoIP provider, in their infrastructure, independent of your physical location and independent of your internet connection. Your desk phones are just endpoints that [register](/blog/sip-registration) to the provider's servers over whatever internet connection they happen to be connected to.

This means that when you move offices, your phone numbers don't need to be "moved" at all. They're already with the provider. What changes is where the phones are plugged in and what internet connection they're using. The process is:

1. Set up internet at the new office
2. Plug your phones into the new network
3. The phones register with the same provider, using the same credentials, and all your numbers, extensions, ring groups, auto attendant, and voicemail work exactly as before

That's it. No porting. No carrier coordination. No weeks of waiting. No risk of losing a number during a transfer. The phone doesn't care what building it's in or what ISP is providing the internet. It registers with the provider, and everything works.

This is a massive simplification compared to the old world of traditional phone lines, where your numbers were tied to a physical circuit in a specific building served by a specific carrier. Moving meant porting those numbers to a new carrier at the new address, a process that could take weeks and had real risk of complications. Hosted VoIP eliminated that entire problem.

## The one thing you absolutely must update: your 911 address

There is one critical step that you cannot skip when moving a hosted VoIP system to a new location: updating your E911 registered address.

When someone dials 911 from a VoIP phone, the system sends your registered address to emergency services so they know where to send help. Unlike traditional phone lines, where the address is inherently tied to the physical circuit, VoIP 911 relies on an address that you (or your provider) registered in a database. If you move offices and don't update this address, a 911 call from your new office will send emergency responders to your old office.

This is a safety issue, not an administrative one. Update the E911 address with your VoIP provider before anyone starts working at the new location. Most providers allow you to do this through their management portal. Some require a support request. Either way, do it on or before move day, verify that it's been updated, and if your provider supports it, place a non-emergency test to confirm the address is correct.

If you have multiple locations or if employees work from different offices, each location should have its own E911 address registered. Some providers support dynamic E911 that associates the correct address based on which network the phone registers from. Ask your provider what options they support.

## When you actually do need to port

Porting, the process of transferring phone number ownership from one carrier to another, becomes necessary in specific situations. If any of these apply to your move, the rest of this post is for you. If none of them apply, you can skip to the next post in the series with the confidence that your numbers will move effortlessly.

**You're switching VoIP providers.** If you're leaving one hosted VoIP provider for a different one as part of the move, your numbers need to be ported from the old provider to the new one. Phone numbers are public resources managed by the North American Numbering Plan Administration (NANPA) under FCC rules. The port transfers the carrier assignment for your numbers from the old provider to the new one.

**You're moving from traditional phone lines to VoIP.** If your current office has POTS lines or a PRI from a traditional carrier and you're switching to hosted VoIP at the new location, your numbers need to be ported from the traditional carrier to the VoIP provider.

**You're moving from an on premises PBX with a [SIP trunk](/blog/sip-trunking) to a different trunk provider.** If you're changing SIP trunk providers as part of the move, the numbers on the old trunk need to be ported to the new provider.

If you're keeping the same VoIP provider and the same SIP trunk provider, no porting is needed regardless of whether you're changing your ISP, moving to a different city, or moving to a different state. The numbers stay with the voice provider, not with the location or the internet connection.

## How porting works when you need it

Number porting is governed by FCC regulations that require carriers to release phone numbers when a customer requests to move them to a different provider. Your new provider (the "gaining carrier") submits a port request to your current provider (the "losing carrier"). The losing carrier verifies the request, and once approved, the number is transferred.

The timeline varies:

**Simple ports** from commercial VoIP providers typically complete in a few business days to two weeks.

**Complex ports** from traditional landline carriers, PRI trunks, or large batches of numbers can take two to four weeks, sometimes longer. These involve more coordination and sometimes require physical circuit disconnections.

The porting process is initiated by your new provider, not by you calling your old provider. Do not cancel your old service before the port is complete. Canceling prematurely can cause the number to be released into a general pool, making recovery difficult or impossible.

## What you need for a port request

Your new provider will need:

The complete list of numbers to be ported, including main numbers, direct lines, fax numbers, and toll free numbers. Your current provider's official name (which may differ from the brand name if they're a reseller). Your account number with the current provider. The authorized name on the account, exactly as it appears in their records. A PIN or password if required by the losing carrier. The billing address on the account. A signed Letter of Authorization, which your new provider will supply.

Every field needs to match the losing carrier's records exactly. A mismatch between "John Smith" on the port request and "John Q. Smith" on the account is enough to get the port rejected, which adds days while the correction is resubmitted.

## Common porting complications

**Information mismatches** are the most frequent cause of delays. Verify every detail with your current provider before submitting. Call them, ask for the exact name and account number on file, and match it character for character.

**Toll free numbers** (800, 888, 877, etc.) use a separate porting process through the RespOrg database. They typically take one to two weeks. Start early and track separately.

**Partial ports** (moving some numbers off an account but not all) can be treated as complex ports by some carriers, extending the timeline even for small number counts.

**Losing carrier delays.** While carriers are legally required to process ports, some process them slowly. Your new provider can escalate with the losing carrier if the port stalls.

**Port completion timing.** The actual cutover happens at a specific time on a specific date. There may be a brief period (minutes to an hour) when calls don't connect correctly during the switch. Schedule the cutover for a low traffic period if possible.

## Temporary numbers during the port

If you're switching providers and the port hasn't completed by the time you need phones working at the new location, your new provider can assign temporary numbers. Your phones work on the temporary numbers for outbound calls and internal testing. When the port completes, the permanent numbers replace the temporary ones automatically.

This is standard practice and avoids the need to time the port completion to exactly match the physical move. Let the port happen on its natural timeline and use temporary numbers to bridge any gap.

## After the port completes

Verify inbound calls by calling each ported number from an external phone and confirming it reaches the right destination. Verify outbound caller ID by placing calls and checking that the correct number displays. Test fax numbers and toll free numbers if applicable.

Once everything is confirmed working on the new provider, cancel the old service. Keep the final bill and note the port completion date for your records in case of billing disputes.

## The bigger picture

The portability of phone numbers on hosted VoIP is one of the technology's most underappreciated benefits. For the majority of businesses moving offices today, the phone number side of the move requires nothing more than plugging phones in at the new location and updating the 911 address. That's a dramatic improvement over the weeks of porting stress and carrier coordination that office moves used to require.

If you're not yet on hosted VoIP and you're planning a move, the move itself is a natural time to make that switch. Porting your numbers to a hosted provider once means that every future move, every future office change, every future ISP switch becomes simpler because your numbers are decoupled from your physical infrastructure forever.

*Next up: [Running Both Locations: The Overlap Period](/blog/overlap-period-both-locations), on managing the transition when you're paying for two offices at once.*

---

### Part 4: Running Both Locations: The Overlap Period

URL: https://voiptest.com/blog/overlap-period-both-locations
Published: 2026-05-04
Tags: office-move, overlap-period, transition, phone-system, planning

*Moving Your Office Without Losing Your Mind (or Your Phones): Part 4 of 8*

For some period of time during your move, you'll be paying for two of everything. Two internet connections, two sets of phone service (or at least the ability to receive calls at both locations), two sets of utilities. It's tempting to minimize this overlap to save money, but the overlap period is actually one of the most valuable phases of the entire move. It's your safety net, your testing window, and your insurance against the unexpected.

The businesses that have the smoothest moves are the ones that budget for a generous overlap and use it well. The businesses that have the worst moves are the ones that try to switch everything on a single weekend and discover problems on Monday morning when customers are calling and employees need to work.

## How long should the overlap be

The right overlap depends on the complexity of your setup and your tolerance for risk. Here are some general guidelines.

**Minimum: two weeks.** This gives you time to install and test the internet connection at the new location, set up and test a few phones, and verify that the basic infrastructure works before committing to the move. Two weeks is tight and assumes everything goes smoothly.

**Recommended: four weeks.** This provides enough time to thoroughly test the new location's connectivity under real conditions, including different times of day and different usage patterns. It also provides buffer for the unexpected: an installation delay, a configuration issue that takes a few days to resolve, or a number porting timeline that slips.

**For complex setups: six to eight weeks.** If you're running an on premises PBX, have a large number of extensions, operate a call center, or have specialized equipment (conference room systems, analog fax machines, door buzzers connected to the phone system), give yourself more time. Each additional component increases the chance that something needs adjustment, and having the old location as a fallback gives you the space to troubleshoot without affecting business operations.

## What to do during the overlap

The overlap period isn't dead time. It's an active testing and validation phase. Here's what should happen.

### Week 1: Infrastructure validation

The internet connection should already be installed at the new location (if you followed the timeline from the first post in this series). During the first week of overlap, connect a computer and a phone to the new connection and test thoroughly.

Run speed tests at different times of day. Morning, midday, and afternoon results can vary significantly on shared connections, as covered in the [Getting the Internet Right series](/blog/cable-internet). Run a [VoIP quality test](/tools/voip-test) to measure latency, jitter, and packet loss under realistic conditions. Place test calls from the new location and listen carefully for audio quality. If you have a second person available, have them call you at the new location from an external number and evaluate the quality from both sides.

If the numbers look good and calls sound clean, you're off to a solid start. If there are issues, you have time to address them: adjusting [QoS settings](/blog/quality-of-service-explained) on the router, contacting the ISP about connection quality, or adding a backup connection if the primary isn't performing as expected.

### Week 2: Equipment setup and configuration

Move a subset of equipment to the new location and configure it. Set up the router or firewall with your production configuration (not a temporary test config). Connect several phones and verify registration, inbound calls, outbound calls, transfers, hold, voicemail, and any other features your team uses daily.

If you're running an on premises PBX, this is when you'd set up the PBX at the new location. Some businesses run the PBX at the new location with a VPN or WAN link back to the old location during the transition, allowing phones at both locations to work off the same system. Others set up a new PBX instance at the new location and migrate extensions individually. The approach depends on your specific setup.

For cloud hosted phone systems, the PBX is in the provider's cloud and doesn't move. You just need phones at the new location that can register to the same provider. This is significantly simpler than moving an on premises system.

### Week 3: Partial move and real world testing

Move a small group of people to the new location and have them work there for a few days using the new infrastructure. This is the real world test that catches issues that controlled testing misses. Maybe the WiFi has a dead spot in the corner conference room. Maybe the firewall is blocking a specific cloud application. Maybe the QoS configuration works for five people but needs adjustment for the full team.

Having a small group at the new location while the rest of the team remains at the old location also tests the ability of the two locations to communicate. Can people at the new office call extensions at the old office? Can they participate in the same conference calls? Can they access the same shared resources?

### Week 4: Full move

With the infrastructure validated, equipment configured, and a partial move successfully completed, the full move is much lower risk. The remaining team moves to the new location. Phones are plugged in, and because the infrastructure is already proven, people should be able to start working almost immediately.

This is also typically when the number port completes (if you're changing providers). The permanent numbers switch over to the new provider, calls start arriving at the new location, and the transition is complete.

## Cloud PBX versus on premises PBX during a move

The type of phone system you have significantly affects the complexity of the move.

**Cloud/hosted PBX:** The phone system itself doesn't move. Your phones register to the provider's servers over the internet. At the new location, you plug in phones, they connect to the internet, register with the cloud provider, and they work. Your extensions, voicemail, auto attendant, ring groups, and all other configuration stays the same because it's all on the provider's servers. This is the easiest scenario.

The main consideration is that the new internet connection needs to be good enough for VoIP. If you're going from a dedicated fiber connection at the old office to a cable connection at the new office, call quality might change even though the phone system is identical. Test call quality at the new location before the full move.

**On premises PBX:** The phone system is a physical server (or virtual machine running on a physical server) that lives in your office. Moving it means either physically relocating the server to the new location, or setting up a new instance and migrating the configuration.

Physical relocation means the PBX is offline during transit, which means your phones don't work during that period. This needs to happen during off hours, and you need to have tested the new location's internet connection with the PBX before committing to the move. The PBX connects to the [SIP trunk](/blog/sip-trunking) through the internet, and if the new connection has a different public IP address (which it almost certainly will), the trunk configuration needs to be updated. If your trunk uses IP authentication, you need to inform your trunk provider of the new IP address before or during the cutover.

Migration to a new instance is cleaner but more work. You set up a new PBX at the new location, configure it with the same settings, and test it alongside the old one. When you're ready to cut over, you point the SIP trunk to the new PBX and switch phones to register with the new system. The old PBX stays running at the old location as a fallback until you're confident the new one is stable.

## Maintaining phone service during the gap

Even with careful planning, there may be a brief period during the physical move when phones at the old location are disconnected and phones at the new location aren't yet fully operational. Minimize this gap, but also plan for it.

**Call forwarding.** Before disconnecting phones at the old location, activate call forwarding on your main numbers to mobile phones or an answering service. This ensures that calls from customers are still answered even if the office phones are temporarily down.

**Voicemail.** Make sure your voicemail system continues to work during the transition. If voicemail is part of your cloud PBX, it'll keep working regardless of which location the phones are at. If it's on your on premises PBX and the PBX is being moved, voicemail will be unavailable during transit. Set up a temporary greeting letting callers know about the move and when normal service will resume.

**Mobile phones.** Your team's mobile phones work regardless of the office move. For the brief period when office phones might be unavailable, having key staff reachable on their mobiles provides continuity.

## Disconnecting the old location

Once the move is complete, the number port is done, everything at the new location is working, and you've had at least a few days of normal operations to confirm stability, you can disconnect the old location.

**Cancel the internet service.** Check your contract terms for any early termination fees if you're still within a term commitment. If possible, time the cancellation to coincide with the end of a billing cycle to avoid paying for a partial month.

**Return equipment.** If you're renting a modem or router from the ISP, return it to avoid equipment charges.

**Cancel phone service at the old location.** If you had phone service separate from your VoIP system (an analog line for a fax machine or alarm system, for example), cancel those lines.

**Document everything.** Keep records of cancellation dates, confirmation numbers, and final bills. Disputes about service charges after a move are not uncommon, and documentation protects you.

*Next up: [Move Day: What to Bring Up First and What to Test](/blog/move-day-phones), the practical sequence for getting operational at the new location.*

---

### Part 5: Move Day: What to Bring Up First and What to Test

URL: https://voiptest.com/blog/move-day-phones
Published: 2026-05-05
Tags: office-move, move-day, checklist, testing, phone-setup

*Moving Your Office Without Losing Your Mind (or Your Phones): Part 5 of 8*

If you've followed the steps in the previous posts, move day should be relatively anticlimactic. The internet is installed and tested. The router and firewall are configured. Phones have been tested at the new location. You know the infrastructure works. Move day is about connecting everything, verifying it's operational, and getting people productive.

But even with preparation, the physical move day has its own logistics. The order in which you bring things online matters, and having a testing sequence ensures that you catch problems early rather than discovering them when a customer calls and can't reach you.

## The order of operations

Work from the infrastructure out. Get the foundation working first, then build on it.

### Step 1: Verify internet connectivity

Before touching anything else, confirm that the internet connection at the new location is up and working. Plug a laptop into the router and verify internet access. Run a quick speed test and a [VoIP quality test](/tools/voip-test) to confirm latency and jitter are within acceptable ranges. This takes a few minutes and confirms that the foundation is solid.

If the internet isn't working, everything else stops. This is why the overlap period and pretesting are so important. If you tested successfully last week but the connection is down on move day, call the ISP immediately. Having the old location still active as a fallback gives you options while the issue is resolved.

### Step 2: Verify the network core

Confirm that the router, firewall, and core switches are operational. Check that DHCP is handing out IP addresses. Verify that [VLAN](/blog/your-local-network) trunks are passing traffic correctly (if you're using VLANs for voice and data separation). Connect a device to each VLAN and confirm it gets the right IP range and can reach the internet.

If you're using a managed firewall, log into the management interface and verify that all rules are active and the configuration matches your production settings. A firewall that got reset to defaults during the move (from a power interruption or accidental reset button press) will block VoIP traffic and leave you troubleshooting for hours.

### Step 3: Bring up phones in stages

Don't plug in all 30 phones at once. Start with two or three at key positions: the main reception phone, one direct line, and one phone in a common area. Connect each one, wait for it to register, and then test:

**Registration.** The phone should show as registered on its display within a minute or two of being connected. If it doesn't register, check the network connectivity from that phone's location (can it reach the PBX or provider?), verify DHCP is providing the correct settings, and check for VLAN issues.

**Inbound calls.** Call the phone from an external number (a mobile phone works). Does it ring? Does the audio sound clear? Test both the handset and the speakerphone.

**Outbound calls.** Place an outbound call to an external number. Verify that it connects and audio works in both directions. Check that the outbound caller ID is displaying correctly.

**Features.** Test hold, transfer to another extension, voicemail, and any other features the phone uses regularly.

Once the first few phones check out, connect the rest in batches. If you're using PoE, watch the switch's PoE utilization as you add phones. A switch that's powering 24 phones and several wireless access points might hit its PoE budget limit (see [IEEE 802.3bt, PoE over four pairs](https://standards.ieee.org/ieee/802.3bt/6749/)), causing some devices to lose power or fail to boot.

### Step 4: Test critical workflows

Once the phones are up, walk through the workflows that matter most to your business. If you have an auto attendant, call the main number and go through every menu option. If you have ring groups, call each group and verify all phones ring as expected. If you use call queues, place a test call into the queue and confirm it routes correctly.

Test conference calling. Test the intercom if you use one. Test the paging system. Test the doorbell or buzzer if it's connected to the phone system. Test fax if you have a fax machine. Every feature that someone depends on should be verified before that person needs to use it.

Then verify 911. A phone that physically moved keeps the emergency address registered against it until someone updates it, so on move day the address that would reach a dispatcher is still the old office. Update the registered address for every number and every device, and verify the dispatchable location detail -- floor, suite, room -- not just the street address. Confirm that 911 can be dialed directly with no prefix, and that the on-site notification reaches a staffed destination at the new office; [the FCC's dispatchable location rules for multi-line phone systems](https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-9/subpart-F/section-9.16) require all three. To confirm the address on file, call your local 911 center's administrative line -- never dial 911 to test.

### Step 5: Verify external access

If your business has remote employees who connect to the office (through a VPN, remote desktop, or other access method), verify that those connections work from outside the new location's network. The public IP address has changed, which means any access rules based on the old IP need to be updated. VPN configurations, remote desktop gateways, security camera systems, and any other service that relies on the office's public IP address all need to be pointed at the new address.

## Who should be on site

On move day, you need specific people available:

**Someone who knows the network.** Your IT person, your MSP, or whoever configured the router, firewall, and phones. This person needs to be physically on site at the new location, not on the phone from somewhere else. Network troubleshooting is dramatically faster when you can walk to the wiring closet and look at the lights on the switch.

**Someone who knows the phone system.** If this is a different person from the network person, have them on site or at least immediately available by phone. PBX configuration changes, trunk adjustments, and extension troubleshooting may be needed.

**A contact at the ISP.** Have the ISP's business support number and your account information ready. If there's a connectivity issue, you don't want to be searching for a phone number while the team waits.

**A contact at the VoIP provider.** Same idea. If trunk registration fails or calls aren't routing correctly, you want to reach their support team immediately.

**The building manager or landlord's contact.** If there's an access issue, a power issue, or a question about the building's infrastructure, you need to reach the right person quickly.

## The move day checklist

Print this and check off each item as you go:

Internet connection active and speed tested. Router and firewall configured and operational. DHCP issuing correct addresses on all VLANs. Core switches powered up with all uplinks connected. First phone connected, registered, and tested for inbound, outbound, and audio quality. Remaining phones connected in batches and registered. E911 registered address updated for every number and every device. Dispatchable location detail (floor, suite, room) verified, not just the street address. Direct 911 dialing confirmed with no prefix required. On-site 911 notification confirmed to reach a staffed destination at the new office. Address on file confirmed via the local 911 center's administrative line (never dial 911 to test). Auto attendant tested. Ring groups and queues tested. Voicemail tested. Conference calling tested. Fax tested (if applicable). Remote access verified (VPN, remote desktop). Backup internet connection tested (if applicable). Building WiFi operational and tested. Printer and copier network connectivity verified.

Not every item will apply to every business, but the framework is the same: verify each layer before building on it, and don't assume anything works until you've confirmed it.

## When something goes wrong

Despite the best planning, something might not work on move day. The key is to have fallback options and to triage effectively.

If the internet is down, everything waits for it. Use a cellular hotspot as a temporary bridge if the ISP needs time to resolve the issue. A few phones can register and work over cellular until the primary connection is restored. One caveat: a 911 call from a phone registering over an improvised cellular bridge may not deliver a usable location to dispatchers, so treat the hotspot as a stopgap for ordinary calls, not a working phone system.

If phones won't register, the issue is almost always DNS, firewall, or VLAN related. Check that the phone can ping the PBX or provider's server. Check that the SIP port (usually 5060 or 5061, per [IANA's registered ports for SIP and SIPS](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml)) isn't being blocked -- a [SIP response code reference](/tools/sip-codes) can help you interpret any error codes you encounter. Check that the phone is on the correct VLAN and getting the right network settings from DHCP.

If calls connect but have no audio, it's the same NAT and firewall troubleshooting covered in the [one way audio post](/blog/one-way-audio) from the troubleshooting series. The new router's SIP ALG settings and firewall rules are the first things to check.

If something is truly broken and you can't fix it within an hour, use the old location as a fallback. Forward calls to mobile phones, send people back to the old office temporarily, and take the time to diagnose and fix the problem properly rather than improvising a broken solution under pressure.

---

*Next up: [After the Move: The First Two Weeks](/blog/after-the-move-first-weeks), covering the issues that surface once everyone starts using the new setup for real.*

---

### Part 6: After the Move: The First Two Weeks

URL: https://voiptest.com/blog/after-the-move-first-weeks
Published: 2026-05-06
Tags: office-move, post-move, troubleshooting, documentation, e911

*Moving Your Office Without Losing Your Mind (or Your Phones): Part 6 of 8*

The furniture is in place. The phones are working. People are at their desks. Move day went smoothly. And then, slowly, the issues start surfacing. Not the dramatic "nothing works" kind of issues that you'd catch on day one, but the smaller, subtler problems that only appear when a full team is using the new setup under real conditions for real work.

The first two weeks in a new office are a shakedown period. Expect things to come up. The goal isn't a flawless first day. It's identifying and resolving issues quickly before they become entrenched frustrations.

## Call quality issues that weren't there during testing

You tested calls during the overlap period and they sounded fine. Now that the whole team is in the office, calls are occasionally choppy during the busiest parts of the day. This is the bandwidth saturation pattern covered in the [afternoon call quality post](/blog/afternoon-call-quality) from the troubleshooting series.

During testing, you had a handful of people using the connection. Now you have everyone: phones, computers, video conferencing, cloud applications, all competing for the same bandwidth simultaneously. The connection that seemed perfectly adequate during light testing may show strain under full production load.

Monitor the internet connection's utilization during the first week, and run a [VoIP quality test](/tools/voip-test) during peak hours to quantify any degradation. If upload utilization approaches the connection's maximum during peak hours, implement [QoS](/blog/quality-of-service-explained) on the router to prioritize voice traffic. If QoS isn't sufficient, you may need to revisit the connection plan. The overlap period (if the old location's internet is still active) gives you a window to upgrade or add a second connection at the new location before the situation becomes urgent.

## WiFi coverage gaps

The WiFi worked great in the conference room during setup. Now that there are 20 devices in the main office, the access point near the front desk is overwhelmed and people in the back corner have weak signal. WiFi under load behaves differently than WiFi with a few devices, and the physical layout of an occupied office (with people, monitors, filing cabinets, and other obstructions) affects signal propagation differently than an empty space.

Walk the office with a phone or laptop and check signal strength in every area where people work or make calls. If there are dead spots or weak areas, the access point placement may need adjustment. Adding an additional access point, moving an existing one, or adjusting channel and power settings can resolve coverage issues.

If anyone is using WiFi for VoIP phones (softphones on laptops, WiFi desk phones), prioritize wired connections for those users. [WiFi voice quality will always be less consistent than wired](/blog/wired-vs-wifi-for-voip), and the extra devices competing for airtime in a fully occupied office make it worse.

## Network discovery and device conflicts

When everything is plugged in at the new location, devices that were on different subnets or VLANs at the old office might end up on the same network. Printers that used static IP addresses at the old location might conflict with DHCP ranges at the new location. A device with a hardcoded IP from the old network (10.0.0.200) might not work if the new network uses a different subnet (192.168.1.x).

Inventory any devices with static IP configurations: printers, network attached storage, security cameras, door access systems, the PBX if it's on premises, and any servers. Verify that their static addresses are within the correct subnet for the new network and don't conflict with the DHCP range.

## SIP trunk adjustments

If your SIP trunk uses IP based authentication and the new location has a different public IP address (which it almost certainly does), the trunk provider's configuration needs to be updated with the new IP. If this wasn't done before the move, outbound calls through the trunk will be rejected because the provider doesn't recognize the new source IP.

Contact your trunk provider (or log into their portal if they have self-service IP management) and update the authorized IP address. If you're on registration based authentication rather than IP authentication, this isn't an issue since the trunk authenticates with credentials regardless of the source IP.

Also check whether the new ISP's firewall or NAT is behaving differently than the old one. Even with the same PBX configuration, a different router's NAT handling can cause one way audio, registration failures, or other SIP issues that didn't exist at the old location. If you're experiencing new SIP problems that weren't present before the move, the router's [SIP ALG](/blog/sip-nat-traversal) setting, NAT type, and firewall rules are the first things to investigate.

## Conference room and shared space issues

Conference rooms have their own set of technology needs that might not have been fully addressed during the move. The conference phone might be on a different VLAN than expected. The display might need network access for wireless presentation. The room's Ethernet ports might not be patched to active switch ports.

Walk through every conference room and shared space in the first week. Test the conference phone, the display connectivity, the wireless presentation system, and the WiFi coverage. These spaces are where problems are most visible (a choppy conference call with a client is noticed immediately) and where they cause the most frustration.

## Remote workers reconnecting

If your team includes remote workers who connect to office resources (VPN, remote desktop, shared drives), the change in public IP address and potentially the change in VPN configuration affects them. Remote workers who connected fine to the old office might not be able to connect to the new one until the VPN or remote access configuration is updated with the new addressing.

Send clear instructions to remote workers before the move about any changes they need to make: new VPN server addresses, updated connection profiles, or new credentials if the access system has changed. Have someone available on move day and the days following to help remote workers troubleshoot connection issues.

## Updating external records

Your office phone numbers are the same (assuming the port went through), but other things have changed that need to be updated:

**Business address in online directories.** Google Business Profile, Yelp, industry directories, and anywhere else your business address appears online. Search engines use this information, and an outdated address can misdirect customers.

**SIP trunk provider records.** Your 911 service address needs to be updated with your VoIP provider. When someone dials 911 from your office phones, the system sends your registered address to emergency services. If this still shows the old address, emergency responders will be sent to the wrong location. This is critically important and should be updated on move day.

**Alarm and security systems.** If your alarm system communicates over the phone line or internet, it needs to work at the new location. Test the alarm system and update the monitoring company with the new address.

**Fax header.** If you use a fax machine, the fax header (the line of text printed at the top of each fax you send) typically includes your business name and phone number, and sometimes your address. Update it.

## Documenting the new setup

The first two weeks are also the right time to document the new network and phone setup while everything is fresh. Record:

The ISP account number, circuit ID, support phone number, and the IP addressing assigned to the connection. The router and firewall configuration (export a backup). The switch port assignments (which port connects to which desk or device). The phone system configuration (extensions, ring groups, auto attendant settings, trunk configuration). The WiFi network names, passwords, and access point locations. The VLAN assignments and IP ranges. Any static IP addresses assigned to specific devices.

This documentation is invaluable for future troubleshooting, for onboarding new IT support, and for the next time you move. The businesses that document their setup during the move avoid the common problem of nobody knowing how anything is configured six months later when something needs to change.

## Setting a review point

Schedule a review two weeks after the move to assess how things are working. Gather feedback from the team: are calls clear? Is the internet fast enough? Are there any recurring issues? Is anything not working that used to work at the old office?

This review is the point where you decide whether the current setup is meeting your needs or whether adjustments are needed. Minor issues can be addressed immediately. Larger issues (like discovering the internet connection isn't adequate for your full team's usage) are easier to solve now than six months from now when the urgency has faded but the frustration hasn't.

---

*Next up: [When to Upgrade Everything Versus Carrying Your Existing Setup Forward](/blog/upgrade-vs-carry-forward), which looks at whether to use the move as an opportunity to modernize.*

---

### Part 7: When to Upgrade Everything Versus Carrying Your Existing Setup Forward

URL: https://voiptest.com/blog/upgrade-vs-carry-forward
Published: 2026-05-07
Tags: office-move, upgrade, phone-system, network-equipment, planning

*Moving Your Office Without Losing Your Mind (or Your Phones): Part 7 of 8*

An office move is a natural inflection point. You're already disrupting your routine, already reconfiguring equipment, already dealing with change. Some businesses see this as an opportunity to upgrade their entire technology stack: new phones, new PBX, new ISP, new network equipment. Others carry their existing setup to the new location as-is, minimizing variables during an already complex transition.

Both approaches have merit, and the right answer depends on your specific situation. The worst approach is to try to do both at the same time without understanding the tradeoffs.

## The case for carrying forward

Moving an existing, working setup to a new location has one enormous advantage: you know it works. The phones, the PBX, the router configuration, the [trunk](/blog/sip-trunking), the auto attendant, the ring groups, everything has been tested and refined over months or years of daily use. Moving it to a new location introduces one major variable (the new internet connection and physical environment) rather than a dozen.

When you carry forward, problems are easier to isolate. If something doesn't work at the new location, you know it worked at the old one, so the issue is almost certainly related to the new environment rather than to the equipment itself. This dramatically narrows the troubleshooting scope.

Carrying forward also costs less in the immediate term. You're not buying new equipment, not paying for new configuration, and not retraining anyone on new systems.

**Carry forward when:**
- Your current setup is working well and meeting your needs
- The move is already complex enough without adding technology changes
- Your budget is stretched by the move itself
- Your team is resistant to change and can't absorb both a move and a new system at the same time
- The equipment is relatively modern and will serve you for at least another few years

## The case for upgrading

A move is one of the rare moments when changing everything is actually easier than normal. You're already disconnecting and reconnecting equipment. You're already reconfiguring network settings. You're already disrupting workflows. Adding new equipment to an already disrupted process is less impactful than introducing new equipment during normal operations when everyone expects things to work seamlessly.

There's also a practical consideration. If your phones are seven years old and showing their age, your PBX is running on hardware that's out of warranty, and your network switches are consumer grade, you're going to need to replace them eventually. Doing it during a move means you do it once. Carrying forward and then upgrading six months later means two disruptions instead of one.

Moving is also the cleanest time to switch from an on premises PBX to a cloud hosted system. At the old location, you'd have to migrate extensions one at a time, manage a hybrid setup during the transition, and coordinate the cutover while people are working. During a move, there's a natural cutover point. The old PBX stays at the old location. The new phones register to the cloud provider at the new location. The transition is clean.

**Upgrade when:**
- Your current equipment is old, out of warranty, or not meeting your needs
- You've been wanting to switch phone systems (especially from on premises to cloud) and the move provides a natural transition point
- The new office has different infrastructure requirements that your current equipment can't meet (more ports, more PoE capacity, different cabling)
- Your current system has reached its capacity and the new office will have more employees or more phones
- The cost of new equipment is within budget and the long term savings (lower maintenance, better features, reduced support costs) justify the investment

## What to upgrade and what to keep

If you decide to upgrade, you don't have to replace everything. Some components are more worth upgrading than others.

**Network switches: often worth upgrading.** If you're running unmanaged consumer switches, the move is a great time to upgrade to managed switches with [VLAN support and PoE](/blog/your-local-network). This is one of the highest impact improvements you can make for VoIP quality. Managed switches let you separate voice and data traffic, prioritize voice packets, and monitor port health. The price difference between a consumer switch and a business managed switch has narrowed significantly in recent years.

**Router/firewall: upgrade if your current one is limiting you.** If your current router doesn't support [QoS](/blog/quality-of-service-explained), doesn't handle SIP well (poor SIP ALG behavior, NAT issues), or doesn't have enough throughput for your connection speed, upgrading during the move makes sense. If your current router works well, carry it forward.

**Phones: upgrade if they're old or if you're changing PBX platforms.** If you're staying on the same PBX, your existing phones will work at the new location with no changes. If you're switching PBX platforms (especially to a cloud provider), you may need new phones that are compatible with the new system, or your existing phones may need to be reprovisioned, which varies in difficulty by phone model.

Modern IP phones from the last five or six years generally support standard SIP and will work with most providers. Phones older than that may lack features like Gigabit Ethernet, HD audio codecs, or adequate processing power for modern firmware. If you're replacing phones, this is a good time to standardize on a single manufacturer and model across the office, which simplifies management.

**Cabling: upgrade if the building requires it.** As discussed in the [building infrastructure post](/blog/new-building-infrastructure), the new building's cabling situation may force your hand. If the existing cabling is inadequate, new cable needs to be run regardless of your other upgrade decisions.

**PBX: the biggest decision.** Changing PBX platforms during a move is the most impactful upgrade and the one with the highest risk. It introduces the most variables: new interface, new features, new configuration, new provider relationship, potential number porting, and a learning curve for everyone. If you're going to do it, plan it as a separate project that happens to coincide with the move, with its own timeline, testing plan, and rollback strategy. Don't treat it as a line item on the moving checklist.

## The hybrid approach

Many businesses take a pragmatic middle path: carry the core system forward and upgrade the components that need it most.

Keep the PBX and phones. Upgrade the switches and router. Run new cabling in the new building. The phone system that everyone knows continues working exactly as before, but the underlying network infrastructure is modernized.

Or: keep the network equipment (it's only two years old and works fine) but switch from an on premises PBX to a cloud provider, using the move as the cutover point.

The hybrid approach lets you pick your battles. Focus the upgrade budget and the disruption tolerance on the components that will make the biggest difference, and leave the rest alone.

## Timing the upgrade relative to the move

If you're upgrading any component, the upgrade should be tested before move day, not on move day.

For new network equipment (switches, router, firewall): configure it at the new location during the overlap period and test with a few devices before the full move.

For a new PBX or cloud phone system: set it up, configure all extensions and features, test thoroughly with temporary numbers, and only cut over to it on or after move day once you're confident it works.

For new phones: provision them and test them on the new system before deploying them to desks. A phone that's been provisioned, tested, and labeled with the user's extension is a phone that can be plugged in on move day and work immediately.

The principle is the same as the rest of this series: reduce the number of variables on move day. Test everything you can in advance. Use the overlap period to validate. Make move day about connecting proven equipment, not debugging new equipment.

---

*Next up: [The Complete Office Move Telecom Checklist](/blog/office-move-telecom-checklist), a consolidated reference of everything covered in this series.*

---

### Part 8: The Complete Office Move Telecom Checklist

URL: https://voiptest.com/blog/office-move-telecom-checklist
Published: 2026-05-08
Tags: office-move, checklist, planning, reference

*Moving Your Office Without Losing Your Mind (or Your Phones): Part 8 of 8*

This final post consolidates everything from the series into a single reference. It's organized as a timeline, starting months before the move and ending a few weeks after. Print it, put it in a spreadsheet, or hand it to whoever is managing the move. The individual posts in this series explain the "why" behind each item. This post is just the "what" and "when."

## 3 to 4 months before the move

**Check internet availability at the new address.** Contact multiple providers, including regional carriers. Don't rely on a single provider's website. Understand what connection types are available (cable, fiber, [dedicated](/blog/dedicated-internet-access), fixed wireless) and what the installation timelines are.

**Evaluate the building's infrastructure.** Check the existing cabling. Determine the pathway from the building's demarcation point to your suite. Ask about any exclusive provider agreements or access restrictions. Verify roof access if you plan to use fixed wireless.

**Address telecom considerations in the lease.** Negotiate the right to use your preferred ISP. Confirm pathway access for cable runs. Clarify any fees for riser access or roof access. Get construction permission in writing if fiber needs to be built.

**Order the internet connection.** For dedicated fiber with construction: order now. For dedicated fiber where infrastructure exists: order now. The sooner you start the process, the more buffer you have for delays.

**Decide whether to upgrade equipment.** Evaluate your current phones, switches, router, and PBX. Decide what's being carried forward and what's being replaced. If upgrading the PBX or switching to a cloud provider, start that planning as a parallel workstream.

## 2 to 3 months before the move

**Order internet connection if not already done.** For cable or shared fiber, this is the latest you should order to have a comfortable buffer.

**If switching VoIP providers, begin the [number porting](/blog/porting-numbers-office-move) process.** If you're staying with the same hosted VoIP provider, no porting is needed. Your numbers live with the provider, not the location. If you are switching providers, gather all required information: account numbers, authorized name, PIN, billing address. Submit the Letter of Authorization to your new provider, and, per [the FCC's guidance on switching providers](https://www.fcc.gov/consumers/guides/porting-keeping-your-phone-number-when-you-change-providers), do not cancel service with the old provider until the port completes. Track the port request status weekly. The months of lead time here are paperwork buffer, not the regulated interval: the port itself is governed by [the FCC's one-business-day rule for simple ports](https://www.ecfr.gov/current/title-47/chapter-I/subchapter-B/part-52/subpart-C/section-52.35), four business days for non-simple ones. What consumes weeks is account validation, rejected requests, and resubmission.

**Order new equipment if upgrading.** Phones, switches, routers, and any other hardware. Allow time for shipping, configuration, and testing.

**Hire a cabling contractor if needed.** If the new building needs new network cabling, schedule the work to complete at least two weeks before the move. This gives time for testing and corrections.

## 1 to 2 months before the move

**Internet installation should be complete.** If it's not, escalate with the provider. You need the connection active with enough time to test before the move.

**Configure the router and firewall at the new location.** Install the production router, configure all rules, VLANs, [QoS settings](/blog/quality-of-service-explained), VPN configurations, and DHCP. Test with a laptop and a phone.

**Test the internet connection thoroughly.** Speed tests at different times of day. Ping and jitter tests to your VoIP provider. Test calls from a phone connected at the new location.

**Cabling should be complete and tested.** Every run should be certified. Patch panels should be labeled. Wall jacks should be labeled to match.

**New equipment should be configured and tested.** If you bought new switches, get them racked and configured. If you bought new phones, provision them and verify they register. Label each phone with the user's name and extension.

## 2 to 4 weeks before the move (overlap period begins)

**Start the overlap period.** Pay for service at both locations. This is your safety net.

**Set up the complete network at the new location.** Switches, wireless access points, and any other infrastructure. Everything should be production-ready.

**Move a small group to the new location for real world testing.** Have them work there for a few days. Collect feedback on call quality, internet speed, WiFi coverage, and any issues.

**Resolve any issues found during testing.** Adjust QoS settings, move access points, update firewall rules, or contact the ISP about connection quality.

**If porting numbers, confirm the port status.** If the port hasn't completed yet, check with your new provider on the expected date. If it's cutting close to the move, plan for temporary numbers. If you're staying with the same hosted VoIP provider, this step doesn't apply since your numbers move with you automatically.

**Prepare fallback plans.** Know how to forward calls to mobile phones. Know how to direct your team to the old office if the new one has a critical failure on move day. Have the ISP's and VoIP provider's support numbers written down (not just saved in a phone that might not work).

## Move day

**Verify internet first.** Plug in a laptop, test connectivity, run a speed test.

**Verify the network core.** Router, firewall, switches, DHCP, VLANs. Everything should be working from the testing period, but confirm it hasn't reset or lost configuration.

**Connect phones in stages.** Start with two or three at key positions. Test registration, inbound calls, outbound calls, and audio quality before connecting the rest.

**Test critical workflows.** Auto attendant, ring groups, call queues, conference calling, voicemail, fax, intercom, paging, and any other features your team relies on.

**Test remote access.** VPN, remote desktop, and any other external access to the office network. Update the public IP address in any configurations that reference it.

**Test 911.** A multi-line phone system has to let someone dial 911 directly, with no prefix, and has to send an on-site notification when they do. Verify both in the dial plan and the notification settings on move day, and confirm the address that reaches dispatchers by calling your local 911 center's administrative line rather than dialing 911 to test.

**[Update your E911 address with your VoIP provider](https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-9/subpart-D/section-9.11).** Do this on move day, on or immediately before the day people start working at the new location. Do not update this weeks or months in advance. The E911 address tells emergency responders where to go when someone dials 911 from your office phones. If you update it early while people are still working at the old office, a 911 call from the old location would send responders to the new address instead. Update it at the point of cutover so the registered address always matches where people are actually working. Note how the current rules fit together: a provider of fixed interconnected VoIP has to deliver an automated dispatchable location with each 911 call, and the registered address you maintain is what stands in when the service can be used from more than one place and automated location is not feasible: softphones, and anyone still working from the old office during the overlap. Either way, make the address dispatchable: floor, suite, or room, not just the street.

**Have key contacts available.** IT/network person on site. ISP support number ready. VoIP provider support number ready. Building manager reachable.

## First week after the move

**Monitor call quality daily.** Listen for reports of choppy audio, one way audio, echo, or dropped calls. These may not appear until the full team is using the connection simultaneously.

**Monitor bandwidth utilization.** Watch for upload saturation during peak hours now that the full team is active.

**Check WiFi coverage with the office fully occupied.** Walk every area and verify signal strength and speed.

**Resolve device conflicts.** Update static IP addresses on printers, servers, cameras, and other devices to match the new network.

**Update SIP trunk IP address if using IP authentication.** Verify outbound calling works and caller ID displays correctly.

**Verify E911 address.** Call your VoIP provider (or check their portal) to confirm the 911 registered address shows the new location. This is a safety issue. Don't skip it.

## Second week after the move

**Gather feedback from the team.** Ask about call quality, internet speed, phone features, and anything that's not working as expected.

**Address any remaining issues.** Persistent call quality problems, WiFi dead spots, features that aren't working correctly, or remote access problems.

**Cancel old location services.** Once you're confident everything works at the new location, cancel the internet, phone lines, and any other services at the old address. Return any rented equipment.

**Document the new setup.** Record ISP account details, router and firewall configurations, switch port assignments, phone system configuration, WiFi settings, VLAN assignments, IP ranges, and static IP allocations.

**Update external records.** Google Business Profile, online directories, business cards, website, invoices, marketing materials, vendors, clients, and anyone else who has your address on file.

**File the final bills from old providers.** Keep records of cancellation dates and confirmation numbers.

## The principle behind the checklist

Every item on this list serves the same goal: reducing the number of unknowns on move day. The businesses that have smooth moves are the ones that test aggressively before the move, build in time for things to go wrong, and treat move day as a deployment of proven infrastructure rather than a day of experimentation.

Start early. Test thoroughly. Maintain the overlap. Document everything. And when something goes wrong, because something always goes wrong, you'll have the fallback plans and the knowledge to resolve it quickly.

---

*This is the final post in the Moving Your Office series. For deeper coverage of the topics referenced throughout, the [Getting the Internet Right series](/blog/isp-foundation) covers ISP selection, the [VoIP From the Ground Up series](/blog/how-does-a-phone-call-actually-work) covers voice fundamentals, and the [When Your Phones Sound Bad series](/blog/choppy-robotic-audio) covers troubleshooting specific symptoms.*

---

## Series: The MSP's Guide to VoIP

A 20-part series for managed service providers adding voice to their stack. Covers business evaluation, network assessment, deployment, ongoing management, advanced architectures, and regulatory compliance.

### Part 1: Should Your MSP Offer Voice Services?

URL: https://voiptest.com/blog/msp-should-you-offer-voice
Published: 2026-03-19
Tags: msp, voice-services, business-strategy, voip-business

*The MSP's Guide to VoIP: Part 1 of 20*

> **Disclaimer:** This post is educational content about the business considerations of offering VoIP services as an MSP. It is not legal advice. Regulations change, interpretations vary, and your specific situation may differ from the general scenarios described here. Consult with a telecom attorney to determine how these regulations apply to your business.

If you run a managed services provider, you have heard the question. Maybe it came from an existing client whose phone contract is up for renewal. Maybe it came from a prospect who assumed you already handled phones. Maybe it came from your own sales team who noticed that every client engagement starts with a conversation about internet and networking but ends with someone else getting the voice deal.

The question is always some variation of: "Can you do our phones?"

And the honest answer for a lot of MSPs is: we could, but should we?

This series is about helping you answer that question with open eyes. Not with a vendor's slide deck that makes everything look like easy margin, and not with the cynicism of someone who tried it once, got burned, and swore it off. Voice services can be genuinely profitable and strategically valuable for an MSP. They can also be a support nightmare that eats into your margins on everything else. The difference comes down to understanding what you are getting into before you commit.

## The revenue case

Let's start with why so many MSPs are interested in voice in the first place: the numbers.

Voice services generate recurring monthly revenue. Per-seat pricing for hosted VoIP platforms typically ranges from $15 to $35 per user per month at retail, with wholesale costs that leave meaningful margin. For an MSP managing a 50-seat client, that could be $750 to $1,750 in monthly recurring revenue from a single account. Multiply across your client base and voice starts to look like a serious line of business.

Beyond the direct revenue, voice creates stickiness. A client who buys internet management, endpoint management, and voice from the same MSP is significantly harder to displace than a client who buys those services from three different providers. When everything is integrated, switching any one piece becomes painful. That stickiness translates to lower churn, longer contract terms, and higher lifetime value per client.

There is also the competitive angle. If you don't offer voice, someone else will. And that someone else now has a relationship with your client, a foot in the door, and a reason to be in their office talking about technology. Today they are selling phones. Tomorrow they are pitching managed services. The MSP that handles voice is in the room for the full technology conversation. The one that doesn't is hoping nobody else brings it up.

## The support reality

Now for the part the vendor slide deck glosses over.

Voice support is different from data support in ways that matter operationally. When a file server goes down, someone opens a ticket. It is disruptive and urgent, but it is a known quantity. You triage, you escalate, you fix it.

When the phones sound bad, or calls are dropping, or a client's caller ID is showing the wrong number, you get a different kind of engagement entirely. Phone problems are immediate and emotional. The person calling you is often in the middle of a conversation with their customer, their patient, their vendor, and the technology is making them look unprofessional. They are not submitting a ticket and waiting. They are calling your support line, and they are frustrated right now.

This changes the cadence of support. Most voice issues happen during business hours, because that is when people are on the phone. Your support team needs to be responsive during exactly the hours when they are also handling every other client's needs. You cannot push voice troubleshooting to evening maintenance windows. The problem is happening live, and the client expects you to be working on it live.

The troubleshooting itself requires different skills than most data support work. Diagnosing why calls sound [choppy and robotic](/blog/choppy-robotic-audio) requires understanding of [jitter buffers](/blog/what-is-jitter-and-why-it-matters) and [packet loss](/blog/understanding-voip-packet-loss). Figuring out why calls are [dropping after a set time](/blog/calls-dropping-after-set-time) requires knowledge of SIP timers and NAT behavior. Understanding why there is [one-way audio](/blog/one-way-audio) means you need to understand how [RTP media streams](/blog/how-does-a-phone-call-actually-work) are established and how firewalls can interfere. These are not skills most MSP technicians have on day one. Building that competency takes time, training, and a willingness to invest in an area that is genuinely complex.

## What clients actually want

When a client asks "can you do our phones," they almost never mean what you think they mean. They are not asking about SIP trunking architectures or codec selection or DSCP marking. They are asking for someone to make phones work and to be responsible when they don't.

What they want is deceptively simple:

**Dial tone.** Phones that work when you pick them up. Calls that connect, sound clear, and don't drop. This is the baseline, and it is non-negotiable. Nobody thanks you for dial tone. They only notice when it is missing.

**Features that match expectations.** Auto attendants, voicemail to email, call recording, ring groups, find-me-follow-me. These are table stakes for any modern business phone system, and clients expect them to work without thinking about them. They also expect you to program and modify these features when their needs change, which happens more often than you might expect. People get promoted, departments reorganize, new hires start, employees leave. Every one of those events touches the phone system.

**A single throat to choke.** This is the big one. Clients do not want to call their phone vendor, who tells them to call their internet provider, who tells them to call their IT company. They want one number to call when something is wrong, and they want that person to own the problem until it is fixed. If you offer voice, you become that person. Even when the problem is actually their [internet connection](/blog/isp-foundation) or their [local network](/blog/your-local-network), the first call comes to you because you are the phone company.

This last point is both the opportunity and the trap. Being the single point of contact is what creates the stickiness and the perceived value. It is also what creates the support burden, because you will be triaging problems that span networking, internet, and telephony, often simultaneously, and the client expects you to sort it out regardless of where the root cause lives.

## The three models

Not all voice offerings are created equal. How you structure your voice offering determines everything: your margin, your support load, your technical requirements, and your regulatory exposure. The spectrum runs from lightest touch to deepest involvement.

**Referral.** You point the client to a hosted VoIP provider, maybe make an introduction, and step back. You might earn a referral fee or a small ongoing commission, but you are not providing the service. The provider handles sales, provisioning, support, and billing. Your involvement is minimal. Your revenue is minimal. Your liability is minimal. But you have also given away the client relationship for that piece of the stack, and you have no control over the client's experience.

**White-label resale.** You sell a hosted platform under your brand (or a shared brand). The underlying infrastructure is operated by a wholesale provider, but the client sees your name on the invoice and calls your team for support. You handle first-line support and configuration changes; the wholesale provider handles the platform, trunking, and carrier relationships. Your margin is better than a referral, and you own the client relationship. But you also own the support obligation, and your ability to resolve problems is limited by what the wholesale provider gives you access to.

**Full stack.** You operate your own PBX infrastructure (physical or virtual), contract directly with [SIP trunk](/blog/sip-trunking) providers for PSTN connectivity, and manage the entire voice environment end to end. Your margin potential is the highest, but so is your operational complexity. You are responsible for platform uptime, security, upgrades, capacity planning, and regulatory compliance. You need staff who understand not just how to configure a phone system but how to maintain one. Even in the evaluation phase, tools like a [Bandwidth Calculator](/tools/bandwidth-calculator) can help you model whether a prospective client's network can support the call volumes you are sizing for.

Each of these models changes the answer to the original question in fundamental ways. We will dig into the specifics of each model in the [next post](/blog/msp-voice-service-models), but the important thing to understand now is that "offering voice" is not a single decision. It is a spectrum, and where you land on that spectrum determines what you need to build, what you need to learn, and what you are signing up for.

## The cost of doing it poorly

Here is where a lot of MSPs get into trouble. They decide to offer voice, pick a platform, do a few deployments, and then discover that they underestimated the support and operational requirements. The result is a voice offering that loses money when you account for the support time it consumes, or worse, a voice offering that damages the client relationships you built on the data side.

Bad voice experiences are visceral. If your managed antivirus misses an update, nobody notices until something happens. If your client's phones sound terrible for a week, everyone in that office notices every single day. They notice when they are on calls with their customers. They notice when they are on calls with each other. And they associate that experience with you, because you are the one who sold them the phone system.

The damage extends beyond the voice service itself. A client who is unhappy with their phones will start questioning everything else you manage. "If they can't get the phones right, what else are they missing?" Voice quality problems erode trust across your entire relationship, not just the voice piece.

The inverse is also true, and this is the part worth paying attention to. An MSP that delivers rock-solid voice becomes deeply embedded in the client's operations. When phones work perfectly and the MSP is responsive to changes and proactive about maintenance, the client sees the MSP as genuinely essential to their business. That perception is worth more than the monthly recurring revenue from the voice service itself.

## The regulatory threshold most MSPs miss

Offering voice services to clients crosses a legal threshold that most MSPs do not see coming. You are no longer just providing IT services. You are entering telecommunications, and that comes with a distinct set of regulatory obligations.

The distinction catches people off guard because of a common confusion around the Universal Service Fund. If you pay USF surcharges on your own business VoIP lines, that is a consumer obligation passed through by your provider. The moment you begin offering interconnected VoIP to clients, you become a voice service provider in the eyes of the FCC, and your obligations change fundamentally.

The key obligations for a voice service provider include: FCC registration, obtaining an Operating Company Number (OCN), STIR/SHAKEN call authentication compliance, registration with the Robocall Mitigation Database, annual FCC filings (Form 499-A), and USF contribution obligations as a provider rather than a consumer. These are not optional, and they apply whether you think of yourself as a phone company or as an MSP that happens to sell phones.

Fines for non-compliance can exceed six figures. The FCC can assess USF contributions retroactively, meaning years of unfiled obligations can land as a single bill. An MSP that has been operating a voice business for three years without proper filings could face a retroactive assessment that erases every dollar of profit those voice services ever generated.

This is not a theoretical risk reserved for large carriers. MSPs operating small voice businesses have the same filing obligations as national providers. The FCC classifies providers based on what they do, not how big they are. Years of profit can be erased overnight by violations you did not know you were committing.

This series covers the regulatory landscape in detail in Parts 17 through 20. Do not treat those posts as optional reading you will get to later. Understand your obligations before you sign your first wholesale agreement.

## The skills gap

Delivering quality voice services requires competency in areas that most MSP technicians are not trained in. This is not a criticism. It is a reflection of the fact that voice and data have historically been separate disciplines, and the MSP model grew up on the data side.

Your team needs to understand [how VoIP works](/blog/what-is-voip) at a level deeper than "it's phone calls over the internet." They need to understand [SIP signaling](/blog/what-sip-actually-is) well enough to read a registration failure and know whether the problem is credentials, DNS, or a firewall. They need to understand [QoS](/blog/quality-of-service-explained) well enough to configure it correctly and to recognize when a quality problem is caused by its absence. They need to understand [how the internet path affects voice](/blog/diagnosing-voip-problems) well enough to tell the difference between a local network problem and a provider problem, because the client is going to expect them to make that determination.

This competency does not appear overnight. You either hire people who already have it (expensive and hard to find), train your existing team (time-consuming but builds long-term capability), or partner with a platform that abstracts away enough of the complexity that your team can operate effectively without deep telephony expertise (which is the appeal of the white-label resale model).

None of these approaches is wrong, but all of them require deliberate investment. The MSPs that struggle with voice are usually the ones that assumed their existing technical team could handle it without additional training or resources.

## Competitive pressure

There is a defensive argument for offering voice that is worth acknowledging separately. The managed services market is consolidating, and the MSPs that are winning are the ones offering a comprehensive technology stack. Voice is part of that stack.

When a prospect is evaluating MSPs, the one that can handle endpoints, servers, networking, security, cloud, and voice has a significant advantage over the one that handles everything except voice. The comprehensive MSP gets a single contract, a single relationship, a single point of accountability. The other MSP gets a more limited engagement and a competitor in the account from day one.

If you are losing deals because you do not offer voice, that is a signal worth paying attention to. It does not mean you should rush into voice without preparation, but it does mean the market is telling you something.

## The honest assessment

Here is how to think about whether voice makes sense for your business right now.

**It probably makes sense if:** you have a stable client base asking for it, you are willing to invest in training or hiring for voice-specific skills, you have (or can build) a support workflow that handles real-time issues during business hours, and you have identified a service model that matches your current capabilities. You do not need to start with full stack. Starting with white-label resale and building competency over time is a perfectly valid path.

**It probably does not make sense if:** your current support team is already stretched thin, you are not willing to invest in voice-specific training, or you are primarily motivated by the revenue without a plan for the support load it creates. Adding voice to an already overloaded operation is a recipe for poor delivery, which will cost you more in damaged client relationships than you will gain in recurring revenue.

**It might make sense later if:** you are interested but not ready. In that case, the best move is to build competency now. Learn the technology, understand the support requirements, get your network fundamentals solid, and position yourself to add voice when your operation can support it. Everything in this series will help with that.

## What this series covers

This is the first post in a twenty-part series that covers everything an MSP needs to know to evaluate, build, and operate a voice business. We will work through service models, client expectations, network readiness, platform selection, provisioning, troubleshooting, operations, and compliance.

The series assumes you already have a working MSP and a solid understanding of networking fundamentals. We are not going to explain what a VLAN is or how DHCP works. If you need a refresher on how VoIP works at a fundamental level, the [VoIP From the Ground Up](/blog/what-is-voip) series is the place to start. If you need to understand the internet connectivity piece, the [Getting the Internet Right](/blog/isp-foundation) series covers that. This series builds on both and focuses specifically on the business and operational aspects of delivering voice as a managed service.

The goal is not to sell you on offering voice. It is to give you the information you need to make a good decision, and if you decide to move forward, to do it in a way that works for your clients and for your business.

---

*Next up: [Voice Service Models: Reseller, Referral, and Full Stack](/blog/msp-voice-service-models), a detailed look at each model, its margins, its support requirements, and its implications for the rest of your business.*

---

### Part 2: Voice Service Models: Reseller, Referral, and Full Stack

URL: https://voiptest.com/blog/msp-voice-service-models
Published: 2026-03-19
Tags: msp, voice-services, business-model, reseller, voip-provider

*The MSP's Guide to VoIP: Part 2 of 20*

> **Disclaimer:** This post is educational content about the business considerations of offering VoIP services as an MSP. It is not legal advice. Regulations change, interpretations vary, and your specific situation may differ from the general scenarios described here. Consult with a telecom attorney to determine how these regulations apply to your business.

In the [previous post](/blog/msp-should-you-offer-voice) we laid out the honest case for and against adding voice to your MSP. If you have decided to move forward, or even if you are still evaluating, the next question is how. And "how" is not a single answer. It is a spectrum that ranges from barely touching the phone system to owning every piece of it.

Where you land on that spectrum determines your margin, your support obligations, your technical requirements, your hiring needs, and your regulatory exposure. Get this decision wrong and everything downstream gets harder. Get it right and you have a framework that scales with your business.

This post walks through each model in detail so you can make an informed choice. We will cover four distinct approaches: referral, white-label resale, co-managed, and full stack. Most MSPs start at one end of this spectrum and move along it over time. Understanding the full range upfront helps you pick a starting point that matches your current capabilities while leaving room to grow.

## Referral: the lightest touch

The referral model is barely a voice business at all, which is exactly its appeal for MSPs who want to address client demand without taking on operational complexity.

Here is how it works. A client asks about phones. You introduce them to a hosted VoIP provider you trust. The provider handles the sales process, provisioning, support, and billing. You might earn a one-time referral bonus or an ongoing trailing commission, typically 5 to 15 percent of the client's monthly spend. Your involvement after the introduction ranges from minimal to zero.

### Where the referral model makes sense

If your MSP is small, your support team is already at capacity, and voice is not a strategic priority, referral is the rational choice. You address the client's need, you keep a voice competitor out of the account (sort of), and you earn some passive income without adding support load.

It also makes sense as a temporary measure while you build voice competency. You can refer clients today while training your team, evaluating platforms, and preparing to move up the spectrum. Better to refer a client to a competent provider than to deliver a mediocre experience yourself.

### Where it falls apart

The fundamental problem with referral is that you have given away the client relationship for a critical piece of infrastructure. The voice provider now has regular contact with your client. They are in the office during phone deployments. They are on the phone when something breaks. And they are a technology company with their own sales team, which means they are positioned to offer other services that overlap with yours.

You also have no control over the client experience. If the provider delivers poorly (bad call quality, slow support, botched number ports), the client may blame you because you made the introduction. Your reputation is tied to a company you do not control.

The commission revenue is real but thin. On a 50-seat client paying $25 per user, a 10 percent trailing commission is $125 per month. That is not nothing, but it is a fraction of what you would earn in a resale model, and it comes without any of the stickiness that makes voice strategically valuable.

### Regulatory implications

In a pure referral model, your regulatory exposure is essentially zero. You are not providing telecommunications services. You are making an introduction. The provider holds the necessary licenses, files the required regulatory reports, and manages compliance with telecommunications law. This is one of the genuinely nice things about the referral model.

## White-label resale: your brand, their platform

White-label resale is where most MSPs land when they get serious about voice. You sell a hosted VoIP platform under your own brand (or a co-branded arrangement) while the underlying infrastructure is operated by a wholesale provider.

The client sees your name on the portal, your logo on the invoices, and your number on the support line. Behind the scenes, the phones register to the wholesale provider's servers, the calls route through their [SIP trunks](/blog/sip-trunking), and the platform runs on their infrastructure. You are the face of the service. They are the engine.

### How the economics work

Wholesale hosted VoIP pricing typically runs $8 to $18 per seat depending on the provider, feature set, and your volume. You sell at retail rates of $20 to $35 per seat. The spread is your gross margin on voice, and it is meaningfully better than referral commissions.

On that same 50-seat client at $28 retail and $12 wholesale, you are generating $800 per month in gross margin. Across ten clients of that size, that is $8,000 per month in recurring gross margin from voice alone. Subtract your support costs and you still have a real business.

Beyond the per-seat margin, many wholesale providers offer revenue share on usage-based services like international calling, toll-free numbers, call recording storage, and fax. These are smaller numbers individually but they add up, and they come with almost no incremental support cost.

### The support model

Here is where the tradeoff lives. You own first-line support. When a client calls because their phones are not working, they are calling you. You need to triage the issue, determine whether it is something on the client's local network, something with their [internet connection](/blog/isp-foundation), or something on the platform side, and either resolve it yourself or escalate to the wholesale provider.

The amount of troubleshooting you can do yourself depends on what the wholesale provider gives you access to. Good wholesale providers give you an admin portal with visibility into registration status, call logs, quality metrics, and configuration. They give you the ability to make most day-to-day changes (adding extensions, modifying call routing, updating auto attendants) without opening a ticket. They have responsive partner support that treats your escalations seriously.

Bad wholesale providers give you a limited portal, restrict your ability to make changes, and have support queues that treat you like a retail customer. The difference between a good and bad wholesale provider will define your experience with the resale model, so platform selection matters enormously. We will cover that in detail later in this series.

The skills your team needs for white-label resale are a step up from referral but not as deep as full stack. They need to understand [how VoIP works](/blog/what-is-voip) well enough to triage issues. They need to be able to distinguish between a network problem and a platform problem. They need to know how to read [MOS scores](/blog/understanding-mos-scores) and recognize when [jitter](/blog/what-is-jitter-and-why-it-matters) or [packet loss](/blog/understanding-voip-packet-loss) is the culprit versus a provisioning error. They need to be comfortable configuring phones, managing call flows, and handling the day-to-day changes that clients request.

What they do not need is deep PBX administration, SIP protocol expertise, or carrier relationship management. The wholesale provider handles those layers.

### The client experience

When done well, white-label resale is invisible to the client. They see your brand, they call your team, and they get their issues resolved. They do not know or care that the platform runs on someone else's infrastructure, just like they do not know or care which data center hosts their Office 365 tenant.

The risk is when the seam between you and the wholesale provider becomes visible. If a client calls you with a [one-way audio](/blog/one-way-audio) problem and you have to tell them "I've escalated it to our platform team and I'm waiting to hear back," you have exposed the layered structure and the client is now wondering who is actually running their phone system. Minimizing these moments requires strong triage skills on your team and a responsive wholesale provider.

### Regulatory implications

This is where things get more nuanced, and it is worth understanding even at this stage. When you resell voice services under your own brand, you may be considered a telecommunications service provider in some jurisdictions. The regulatory landscape varies significantly by country and by state or province within countries.

In the United States, reselling VoIP services can trigger obligations to file with the FCC, contribute to the Universal Service Fund, comply with CPNI (Customer Proprietary Network Information) rules, and support E911 emergency calling. Some wholesale providers structure their agreements so that they remain the provider of record for regulatory purposes, which keeps these obligations on their side. Others structure it so that you, as the reseller, bear some or all of these obligations.

There is an important distinction here that catches many MSPs off guard. If you pay USF surcharges on your own business VoIP lines, that is a consumer obligation passed through by your provider. It does not mean you are compliant as a provider. The moment you begin offering interconnected VoIP to clients, you may cross the threshold into voice service provider territory, with separate obligations including FCC registration, obtaining an Operating Company Number (OCN), and filing Form 499-A. Even in a resale arrangement, depending on how the wholesale agreement is structured, you, not the wholesale provider, may be the entity with FCC filing obligations. Read the agreement carefully and understand which party is the provider of record before you sign.

You need to understand which structure your wholesale agreement uses before you sign it. "I didn't know I had regulatory obligations" is not a defense that regulators find compelling. We will cover the compliance landscape in detail in the final section of this series (posts 17 through 20), but the takeaway for now is: ask the question early and get a clear answer.

## Co-managed: shared responsibility

The co-managed model sits between white-label resale and full stack. You deploy and manage the phone system on the client's behalf, but you do it in partnership with a provider who retains responsibility for certain layers of the stack.

This model takes different forms depending on the provider and the arrangement. In one common version, you deploy a provider's on-premises or cloud PBX platform at the client site, configure and manage it, and handle first-line support. The provider manages the trunking, maintains the platform software, and provides escalation support. You have deeper access to the system than in a resale model (you might have full admin access to the PBX rather than a limited portal), but the provider still owns the infrastructure components.

In another version, you deploy your own PBX infrastructure (say, an open-source PBX on a VM) but use the provider for [SIP trunking](/blog/sip-trunking) and PSTN connectivity. You manage the PBX. They manage the trunk. This is a common stepping stone toward full stack because it lets you build PBX expertise while outsourcing the carrier relationships and regulatory compliance associated with trunking.

### Economics of co-managed

The margins in co-managed arrangements are higher than resale because you are delivering more value and taking on more responsibility. Per-seat economics vary widely depending on the specific arrangement, but the general pattern is that you capture more of the revenue because you are doing more of the work.

The flip side is that the work is real. You are provisioning PBX systems, managing SIP trunk configurations, handling firmware updates, and troubleshooting at a deeper level than resale requires. Your team needs stronger telephony skills, and the per-client support time is higher.

### When co-managed makes sense

Co-managed works well for MSPs that have some telephony expertise on staff and want to offer a more customized solution than a hosted platform allows. Some clients need PBX features or integrations that hosted platforms do not support well, and co-managed gives you the flexibility to deliver those without taking on the full complexity of owning the entire stack.

It is also a natural progression from resale. Once your team is comfortable with VoIP fundamentals and day-to-day voice support, taking on PBX management is a reasonable next step that increases your value to clients and your revenue per seat.

### Regulatory implications

In a co-managed model, the regulatory picture depends heavily on the specific arrangement. If the provider retains the trunking relationship and acts as the provider of record, most regulatory obligations stay on their side. If you are contracting for trunks yourself, you start picking up obligations around E911, number portability, USF contributions, and potentially state-level telecommunications licensing.

The general rule is that the closer you get to owning the connection between the PBX and the public telephone network, the more regulatory surface area you take on. Trunking is where the regulatory weight lives.

## Full stack: owning everything

In the full-stack model, you operate the PBX infrastructure, contract directly with SIP trunk providers for PSTN connectivity, manage phone numbers, and own the entire voice environment end to end. You are not reselling someone else's platform. You are the platform.

This is where the MSPs with deep telephony expertise live. It is also where the highest margins live, and where the highest operational complexity lives.

### What full stack actually requires

Operating a full-stack voice provider means you are responsible for:

**Platform infrastructure.** Whether you run on-premises PBX hardware, virtual machines in a data center, or a cloud-hosted PBX, you are responsible for its uptime, performance, security, and maintenance. PBX software needs updates. Databases need backups. Certificates need renewal. Capacity needs planning. This is similar to managing any other server infrastructure, but with the added pressure that downtime means no dial tone for every client on that platform.

**SIP trunk management.** You contract directly with one or more Internet Telephony Service Providers for PSTN connectivity. You manage the [trunk configuration](/blog/sip-trunking), monitor trunk health, handle capacity planning, and deal with trunk-side issues like [authentication failures](/blog/sip-authentication-security) or codec mismatches. You need to understand [SIP registration](/blog/sip-registration), [SIP signaling](/blog/what-sip-actually-is), and how to read a SIP trace when things go wrong.

**Number management.** You own the relationship with the number providers. Porting numbers in, porting numbers out, provisioning new DIDs, managing toll-free numbers, configuring [caller ID](/blog/caller-id-problems). All of it runs through you. Number porting alone can be a significant operational burden, especially during the first few months of a client engagement when you are migrating their existing numbers.

**E911 and emergency services.** If you are providing the dial tone, you are responsible for ensuring that emergency calls work. This means E911 provisioning for every endpoint, keeping location data current as employees move or work remotely, and complying with applicable emergency services regulations. Getting this wrong has consequences that go beyond fines. It is a safety issue.

**Client provisioning and management.** Onboarding a new client means deploying and configuring their PBX environment, provisioning phones, setting up call flows, training users, and migrating their numbers. Ongoing management means handling moves, adds, and changes (MACs) as their organization evolves.

### The margin math

Full-stack margins are compelling. When you own the PBX infrastructure and buy trunking at wholesale rates, your per-seat cost can be remarkably low. SIP trunk costs for a channel of PSTN connectivity might run $1 to $3 per month. PBX infrastructure costs, amortized across your client base, add another few dollars per seat. Your total cost per seat might be $5 to $10, compared to $12 to $18 in a resale model. At a $28 retail price, that is a significant improvement in gross margin.

But gross margin is not the whole picture. Your operating costs are higher because you need more skilled staff, more infrastructure, and more time per client for provisioning and support. The net margin depends entirely on your operational efficiency and your scale. At small scale, the fixed costs of running your own platform can eat into or exceed the margin advantage. At larger scale, the economics become very attractive.

### The risk profile

Full stack carries risks that the other models do not. Platform outages affect every client simultaneously. A security vulnerability in your PBX software is your problem to patch. A misconfigured trunk can cause [call quality issues](/blog/choppy-robotic-audio) or outright outages across your client base. And because you are the platform, there is no wholesale provider to escalate to. You are the last line.

This does not mean full stack is a bad choice. It means it is a choice that requires genuine preparation, adequate staffing, and robust operational processes. MSPs that run successful full-stack voice operations have typically been building their telephony expertise for years before taking on the platform responsibility.

### Regulatory implications

Full stack has the most significant regulatory exposure of any model. When you are providing interconnected VoIP, meaning you are the entity that connects calls to the public telephone network, you are a telecommunications service provider in the eyes of regulators. "Interconnected VoIP" is the FCC's term for VoIP service that connects to the PSTN, and it is the trigger for provider classification.

In the United States, this means FCC registration, obtaining an Operating Company Number (OCN), USF contributions, state-level telecommunications licensing in every state where you have clients, CPNI compliance, E911 obligations, STIR/SHAKEN compliance, Robocall Mitigation Database filing, number portability compliance, and potentially local telecommunications taxes and surcharges. The regulatory overhead is not trivial. FCC enforcement actions against voice service providers for compliance failures have resulted in penalties exceeding six figures, and the FCC can assess USF contributions retroactively, meaning years of unfiled obligations can land as a single bill. For a small MSP, a single enforcement action can erase years of profit.

Some MSPs that operate full-stack voice providers structure their operations to minimize regulatory exposure, for example by using a licensed ITSP for trunking while managing the PBX themselves, which keeps the trunk-side regulatory obligations on the ITSP. This is essentially the co-managed model applied at scale, and it is a legitimate approach. But it limits some of the cost advantages of true full stack.

We will go deep on the regulatory landscape in posts 17 through 20. For now, the key point is that if you are considering full stack, regulatory compliance needs to be part of your planning from day one, not an afterthought.

## Where most MSPs start versus where the money is

The pragmatic reality is that most MSPs start with white-label resale. It offers a reasonable margin, a manageable support load, and a well-defined boundary between what you are responsible for and what the wholesale provider handles. It lets you build voice competency and client volume without betting your business on a platform you are not ready to operate.

The money, in terms of per-seat margin, is in full stack. But the money only materializes if you have the scale, the expertise, and the operational maturity to run a platform efficiently. A small MSP running a full-stack voice operation with 200 seats is probably spending more on overhead than the margin advantage justifies. A larger MSP with 2,000 seats is in a very different position.

The most common progression looks like this: start with resale to learn the market and build competency, move to co-managed as your team's skills deepen and clients need more customization, and consider full stack when you have enough volume to justify the infrastructure investment and enough experience to operate it reliably.

There is no shame in staying at resale forever if it serves your business well. Not every MSP needs to become a telecom company. The point is to make a deliberate choice rather than drifting into a model by default.

## How your choice affects the rest of this series

The service model you choose determines the relevance of different topics in this series. If you are doing white-label resale, the posts on [network readiness](/blog/your-local-network), [QoS](/blog/quality-of-service-explained), and [troubleshooting](/blog/diagnosing-voip-problems) are directly applicable to your daily work. The posts on platform operations and capacity planning are useful context but not your direct responsibility. The compliance posts are relevant but your wholesale provider shoulders most of the weight.

If you are heading toward co-managed or full stack, everything in this series is directly applicable. The network posts, the platform posts, the provisioning posts, the troubleshooting posts, and the compliance posts all describe things you will be doing yourself.

Regardless of your model, the next post matters for everyone. Client expectations around voice support are one of the most commonly underestimated aspects of adding voice to an MSP, and getting them right from the start saves an enormous amount of pain later.

---

*Next up: [Setting Client Expectations: What Voice Support Actually Looks Like](/blog/msp-voice-support-expectations), covering why voice support is different from data support, how to scope it in your MSA, and how to position yourself when the blame game starts.*

---

### Part 3: Setting Client Expectations: What Voice Support Actually Looks Like

URL: https://voiptest.com/blog/msp-voice-support-expectations
Published: 2026-03-20
Tags: msp, voice-support, client-management, msa, support-scope

*The MSP's Guide to VoIP: Part 3 of 20*

You have decided to offer voice. You have picked a [service model](/blog/msp-voice-service-models). Now comes the part that determines whether your voice offering is a profitable addition to your business or a slow-motion erosion of your margins and your client relationships: setting expectations.

Voice support is different from data support. Not harder in every case, but different in ways that catch MSPs off guard if they are not prepared. The nature of the problems is different. The emotional intensity is different. The timing is different. And the dynamic between you, the client, and any upstream providers is different. If you scope and deliver voice support the same way you scope and deliver data support, you will be underwater within six months.

This post is about understanding those differences, building them into your service agreements, and positioning yourself so that you are solving problems rather than absorbing blame.

## Why voice problems feel different

When a file server goes down, the impact is real but the experience is delayed. Someone tries to open a file, gets an error, and opens a ticket. The ticket sits in a queue for a few minutes. A technician picks it up, starts working on it, and communicates progress. The whole interaction happens through a structured support workflow. It is disruptive, sometimes urgently so, but it fits the established model of how IT support works.

When the phones sound bad, the experience is immediate and personal. The person experiencing the problem is not interacting with a file. They are interacting with another human being. They are on a call with a customer, a patient, a vendor, or a colleague, and the technology is failing in real time, in their ear, in a way that makes them sound unprofessional. A [choppy, robotic-sounding call](/blog/choppy-robotic-audio) does not just prevent work from getting done. It embarrasses the person on the call.

This emotional dimension changes everything about how the support interaction unfolds. The person reporting a voice problem is not calmly submitting a ticket with steps to reproduce. They are frustrated, often while still on the bad call or immediately after hanging up. They want acknowledgment that the problem is real, they want to know it is being worked on right now, and they want it to not happen again. The tolerance for "we'll look into it and get back to you" is measured in minutes, not hours.

This is not a criticism of clients. It is a recognition that voice is inherently a real-time, human-facing service. When email is slow, people are annoyed. When phones sound bad, people feel it. Understanding this emotional reality is the first step toward building a support model that actually works.

## The cadence of voice support

Data support issues distribute somewhat evenly throughout the day, with spikes around the start of business as people log in and discover problems. Voice support issues concentrate almost entirely during business hours, because that is when people are making and receiving calls.

This sounds obvious, but the operational implication is significant. Your support team's busiest hours for voice are the same hours they are busiest for everything else. You cannot defer voice troubleshooting to evening maintenance windows. You cannot batch voice tickets for after-hours work. The problem is happening live, the client knows it is happening live, and they expect you to be working on it live.

For MSPs that staff a help desk with defined shifts, this means your daytime team needs the capacity and the skills to handle voice issues on top of everything else they are already doing. For MSPs that rely on a smaller team with on-call escalation, it means voice escalations will happen during business hours when the on-call person might already be engaged with other work.

The other cadence issue is seasonal and situational. Voice support volume spikes during specific events: office moves, phone system changes, internet provider cutbacks, new employee onboarding waves, and, often, after any change you make to the client's network. [QoS configuration changes](/blog/quality-of-service-explained), firewall rule updates, switch replacements, and VLAN modifications can all affect voice in ways that are not immediately obvious. Every network change is a potential voice ticket, and the voice ticket will arrive during business hours when the impact is felt.

## What voice support actually covers

Before you can scope voice in your service agreement, you need to understand the categories of work that voice generates. It falls into three broad buckets.

### Break-fix: something is wrong right now

This is the reactive support that most MSPs think of first. A phone is not registering. Calls are [dropping after 30 minutes](/blog/calls-dropping-after-set-time). There is [one-way audio](/blog/one-way-audio) on every call. The auto attendant is playing the wrong greeting. [Caller ID](/blog/caller-id-problems) is showing the wrong number. There is [echo on calls](/blog/echo-on-voip-calls) or [noticeable delay](/blog/audio-delay-talking-over) that makes conversations awkward.

Break-fix voice support requires your team to triage the problem across multiple layers: the phone itself, the [local network](/blog/your-local-network), the [internet connection](/blog/isp-foundation), and the phone platform or [SIP trunk](/blog/sip-trunking). The diagnostic skills required are specific to voice. Understanding [jitter](/blog/what-is-jitter-and-why-it-matters), [packet loss](/blog/understanding-voip-packet-loss), [MOS scores](/blog/understanding-mos-scores), and [SIP behavior](/blog/what-sip-actually-is) is not optional. It is the baseline for being able to identify where a problem lives. Our [diagnostic framework post](/blog/diagnosing-voip-problems) covers the technical methodology, and it is worth having your team internalize that material.

The volume of break-fix work depends heavily on how well the system was deployed initially and how stable the underlying network is. A well-deployed system on a solid network with proper [QoS](/blog/quality-of-service-explained) generates very few break-fix tickets. A poorly deployed system on a marginal internet connection generates a steady stream of them. The quality of your initial deployment is the single biggest lever you have on your ongoing support costs.

### Moves, adds, and changes: the ongoing churn

This is the work that most MSPs underestimate. A new employee starts and needs a phone provisioned and an extension assigned. An employee leaves and their extension needs to be removed, their voicemail forwarded, and their direct number reassigned. A department reorganizes and the ring group membership needs to change. The office manager wants the auto attendant menu updated. Someone got promoted and their caller ID name needs to change on outbound calls. And when the request is to turn on call recording, treat it as more than a checkbox: [recording consent requirements vary by state](/blog/call-recording-laws-by-state), and enabling it without the right disclosure announcement creates legal exposure for the client.

These are not break-fix issues. Everything is working as configured. The client just needs the configuration to change. And these requests come in constantly. Every personnel change, every organizational shift, every new business need touches the phone system. In a 50-person office, you might see two to five MAC requests per month during stable periods, with spikes during hiring seasons or reorganizations.

MACs are individually small but collectively significant. Each one takes 10 to 30 minutes depending on complexity. A few per month is manageable. A dozen per month starts to add up, especially if your team has to context-switch from other work to handle them.

How you handle MACs in your service agreement matters. Some MSPs include a defined number of MACs per month in the base price and charge for overages. Others include unlimited MACs and build the expected volume into their pricing. Others charge for all MACs on a time-and-materials basis. The right approach depends on your client base and your cost structure, but the important thing is that you have explicitly addressed it. "We didn't think about MACs" is how MSPs end up doing hours of unpaid voice work every month.

### Proactive management: keeping things running

This bucket includes firmware updates on desk phones and ATAs, monitoring registration status and call quality metrics, reviewing call logs for anomalies, managing certificate renewals on SIP trunks, and ensuring that backup configurations and [failover paths](/blog/redundancy-failover) are still valid.

The amount of proactive work depends on your service model. In a white-label resale model, the wholesale provider handles platform-level maintenance and you focus on endpoint management. In a co-managed or full-stack model, you are responsible for the full range of proactive maintenance.

Regardless of model, some proactive work falls to you. Phone firmware updates can change behavior in ways that affect call quality or feature operation. Network changes at the client site can degrade voice without triggering an immediate outage. And [afternoon congestion patterns](/blog/afternoon-call-quality) can creep in gradually as a client's bandwidth usage grows, producing intermittent quality issues that nobody reports because each individual instance seems minor.

Building proactive monitoring into your voice operations reduces break-fix volume and catches problems before clients notice them. It also gives you data to show clients when they ask "how are the phones doing," a question that comes up more often than you might expect, because phones are something people have feelings about.

## Scoping voice in your MSA

Your master service agreement needs to address voice as a distinct service category, not as an afterthought buried in "IT support." The specifics depend on your service model and your client base, but there are several areas that need explicit treatment.

### Service scope definition

Define what is included and what is not. This sounds basic, but ambiguity in scope is where most voice support disputes originate. Be specific about:

**What you support.** The phone system platform, desk phones and softphones, call routing configuration, voicemail, auto attendants, and the network infrastructure that carries voice traffic.

**What you do not support.** The client's internet connection (unless you manage it), carrier-side issues on the PSTN, the far end of the call (if the person they are calling has bad audio, that is not your problem), and integrations with third-party applications unless specifically listed.

**MACs.** How many are included, what counts as a MAC, and how overages are handled.

**Hours of support.** Voice support during business hours is essential. After-hours voice support is a separate conversation. Most voice problems are not true emergencies outside of business hours because nobody is on the phone, but some clients run evening or weekend operations where phones are critical. Define what coverage the client is paying for.

### Response time commitments

Voice support should have tighter response time commitments than general IT support, at least for issues that affect active calls. When phones are down or call quality is severely degraded, the impact is immediate and visible to everyone in the office and to everyone they are trying to talk to. A four-hour response SLA that works fine for a printer issue is not appropriate for a system-wide voice outage.

A common structure is a tiered response model: critical voice issues (total outage, widespread quality degradation) get a 15 to 30 minute response commitment during business hours, while non-critical voice issues (single phone not working, feature configuration request) follow your standard SLA.

Be careful about the difference between response time and resolution time. You can commit to responding quickly. Committing to resolving quickly is dangerous because voice issues often involve third parties (the internet provider, the wholesale platform, the SIP trunk provider) whose response times you do not control. Promise fast response and transparent communication. Do not promise fast resolution for problems that might not be in your control to resolve.

### Exclusions and limitations

Your agreement should explicitly address scenarios that fall outside your support scope. The most common ones:

**Internet-caused quality issues.** If the client's internet connection is introducing [jitter](/blog/what-is-jitter-and-why-it-matters) or [packet loss](/blog/understanding-voip-packet-loss) that degrades call quality, you can identify the problem and communicate it, but fixing it requires the client to engage their ISP or upgrade their connection. If you also manage their internet, this is your problem. If you don't, it is not. Make this clear.

**Client-caused issues.** If the client plugs a desk phone into a consumer-grade switch they bought at a big box store, or if they connect VoIP phones over [WiFi against your recommendation](/blog/wired-vs-wifi-for-voip), the resulting quality issues are a consequence of their decisions, not your service. Document your recommendations in writing, and reference them in your agreement so there is no ambiguity later.

**Upstream provider issues.** If the wholesale platform has an outage, or the SIP trunk provider has a routing problem, your obligation is to identify the issue and communicate with the client, not to fix infrastructure you do not control. The client deserves transparency about what is happening and what you are doing about it, but your SLA should not penalize you for someone else's outage.

## The blame game and how to handle it

Voice problems create a blame dynamic that does not exist in most other areas of IT support. When phones sound bad, there are typically multiple parties involved: the MSP, the internet provider, the phone platform or trunk provider, and possibly the client's own network decisions. Each party has an incentive to point at someone else.

The client does not care whose fault it is. They care that it gets fixed. And they are going to direct their frustration at whoever they consider responsible, which is you, because you sold them the phone system.

The most effective way to handle this dynamic is to position yourself as the objective investigator rather than a defendant. When a voice quality issue arises, your role is to determine where the problem lives, communicate that finding clearly, and drive resolution regardless of which party needs to act.

This means you need the tools and skills to actually make that determination. If a client reports [choppy audio](/blog/choppy-robotic-audio), you need to be able to determine whether the cause is local network congestion, internet path degradation, or a platform-side issue. You need data to back up your finding, not just an opinion. A [VoIP quality test](/tools/voip-test) that shows degradation during specific hours, a packet capture that shows [jitter](/blog/what-is-jitter-and-why-it-matters) spikes correlated with bandwidth saturation, a traceroute that shows latency introduced at a specific hop. These are what turn "we think it's the internet" from a deflection into a diagnosis.

When you can show a client concrete evidence that the problem is their ISP's congestion during [peak afternoon hours](/blog/afternoon-call-quality), you have transformed the conversation. You are not deflecting blame. You are providing expertise. The client now knows what the problem is and what needs to happen to fix it, and they see you as the person who figured it out rather than the person who caused it.

This investigative positioning also protects you when the problem actually is on your side. If a phone is misconfigured or a QoS policy is wrong, owning it quickly and fixing it builds trust. Clients do not expect perfection. They expect honesty and competence. Finding and fixing your own mistakes is competence. Denying problems or deflecting blame is what destroys trust.

## Building the support workflow

A few practical considerations for how voice support fits into your existing support operations.

### Triage training

Your first-tier support team needs a voice-specific triage checklist. When a voice ticket comes in, the first questions should establish whether the problem is affecting a single phone, multiple phones, or all phones; whether it is intermittent or constant; whether it started after a change; and whether the client's internet connection is showing any issues. This basic triage immediately narrows the problem space and determines whether it needs escalation to a voice specialist or can be handled at first tier.

The triage checklist should reference the [diagnostic framework](/blog/diagnosing-voip-problems) in a simplified form. Not every first-tier technician needs deep VoIP expertise, but every one of them needs to know how to gather the right information so that whoever does the deeper troubleshooting has something to work with.

### Escalation paths

Voice issues often cross organizational boundaries. You may need to escalate to your wholesale provider's partner support, to the client's ISP, or to a SIP trunk provider. Having established escalation contacts and processes for each of these parties before you need them saves critical time during an outage.

For your wholesale provider, know the partner support number, the expected response time, and what information they need when you escalate. For client ISPs, know who to call (the business support line, not the residential queue) and what the client's account information is. For SIP trunk providers, know the support process and have your trunk credentials accessible.

### Documentation habits

Voice environments change frequently due to MACs, and undocumented changes are one of the most common causes of voice issues that are difficult to troubleshoot. Build a documentation habit that captures every voice configuration change: what was changed, when, by whom, and why. When a problem appears three weeks after a change, that documentation is what connects the dots.

Document the client's voice environment at deployment and keep it current. Extension assignments, call flow logic, auto attendant menus, ring group membership, trunk configuration, network topology relevant to voice, QoS settings, and phone firmware versions. This documentation is both an operational tool and a business asset. It is what makes it possible for any member of your team to support the client's voice environment, not just the person who set it up.

## What this means for your business

Adding voice support to your MSP changes the shape of your support operation. It adds real-time urgency during business hours. It requires skills that your team may not have today. It creates a blame dynamic that needs proactive management. And it generates a category of low-complexity but high-volume work (MACs) that can quietly consume margins if not properly scoped.

None of this is a reason not to offer voice. It is a reason to offer voice with open eyes, with proper scoping, and with a support model designed for the specific demands that voice creates. The MSPs that succeed with voice are not the ones with the best technology. They are the ones with the best operational discipline around how voice support is scoped, delivered, and managed.

The next post shifts from the business and operational side to the technical foundation. Before you can deploy a phone system, you need to ensure the client's network can carry voice traffic reliably. That means understanding what voice needs from a network and how to evaluate whether a client's environment is ready.

---

*Next up: Part 4 covers network readiness assessments, including what to test, what to look for, and how to know whether a client's network is ready for voice before you deploy a single phone.*

---

### Part 4: Assessing a Client's Network for VoIP Readiness

URL: https://voiptest.com/blog/msp-network-assessment
Published: 2026-03-20
Tags: msp, network-assessment, voip-readiness, site-survey, network-audit

*The MSP's Guide to VoIP: Part 4 of 20*

You've scoped the project, the client has signed off, and now it's time to figure out what you're actually working with. The network assessment is where the rubber meets the road. It's the difference between a smooth VoIP deployment and a three-month firefight where every other ticket is "my calls sound terrible."

This isn't a theoretical exercise. This is the site survey checklist, the stuff you actually walk through before you commit to a go-live date. We'll cover the internet connection, the internal network, the measurements you need to take, and how to interpret the results. By the end, you'll have a clear framework for sorting clients into three buckets: ready to go, needs some work, or not happening until we fix some things.

## Start with the Internet Connection

The WAN link is the single most important factor in VoIP quality. You can have a perfectly configured internal network, but if the internet connection can't sustain real-time media, none of it matters. Here's what to evaluate.

### Connection Type

What kind of circuit are they on? This tells you a lot before you even run a test.

**Fiber** is the gold standard. Symmetric bandwidth, low latency, minimal jitter. If the client is on fiber, you're already in good shape. See our [deep dive on fiber](/blog/fiber-internet) for the specifics.

**Cable** is where things get interesting. Downstream is usually fine, but upstream is often the bottleneck. A 200/10 cable connection looks great on paper until you realize those 10 Mbps upstream need to carry voice, video conferencing, cloud backups, and whatever else is fighting for that pipe. We've written extensively about [cable internet and VoIP](/blog/cable-internet).

**DSL** varies wildly depending on distance from the DSLAM. If they're close, it can work. If they're far, latency and bandwidth will be a problem. Fixed wireless and satellite connections introduce their own challenges: higher latency, weather sensitivity, and shared capacity that can degrade during peak hours.

If you're walking into a site running on a basic cable connection with 20+ users, start thinking about whether a [dedicated internet access](/blog/dedicated-internet-access) circuit makes sense. DIA gets you symmetric bandwidth, an SLA with teeth, and priority repair. It costs more, but it's the right call for sites where voice quality is non-negotiable.

### Upload Speed, Specifically

This is the number that matters most, and it's the one most people overlook. Every concurrent VoIP call consumes roughly 80-100 Kbps upstream using G.711, or about 24-32 Kbps with G.729. That doesn't sound like much, but it adds up fast when you factor in overhead, and it's competing with everything else on the network.

Do the math. Count the maximum number of concurrent calls the client will realistically have. Multiply by 100 Kbps for a conservative G.711 estimate. That's your voice traffic baseline, or use our [Bandwidth Calculator](/tools/bandwidth-calculator) to model it with the exact codec and overhead. Now compare that to the available upstream bandwidth. Not the advertised speed, but the actual measured speed during business hours.

A good rule of thumb: voice traffic should never consume more than 30% of available upstream bandwidth. If it does, you're going to have problems, especially during peak usage. This is a concept we explore further in our piece on [why call quality drops in the afternoon](/blog/afternoon-call-quality).

### Provider and SLA

Who's the ISP? Do they offer an SLA? What does it actually guarantee? A residential cable connection with "best effort" service is a very different animal than a business-class circuit with uptime guarantees and a four-hour repair window.

Ask for the ISP's contact information, the account number, and the current contract terms. You'll want this when things go sideways, and at some point, they will. Knowing whether you can escalate to a business support team or you're stuck in a residential queue matters.

Also check: is there a single point of failure? One ISP, one circuit, one path into the building? For clients where uptime is critical, a secondary WAN link with automatic failover is worth discussing. It doesn't have to be another fiber circuit. Even an LTE backup can keep phones alive during an outage.

### Current Utilization

Don't just measure bandwidth capacity. Measure what's actually being used. The client might have a 100 Mbps symmetric fiber connection, but if cloud backups are saturating the upstream every day at 2 PM, that capacity is spoken for.

If the client has a firewall or router with traffic monitoring, pull the utilization graphs. Look at the patterns over a full business week. You're looking for sustained periods where utilization exceeds 70% of available bandwidth. Those are your danger zones.

If there's no monitoring in place, that's a finding in itself. You'll want to deploy something (even temporarily) to get a baseline before committing to a deployment date. For more on how the [ISP connection forms the foundation](/blog/isp-foundation) of everything else, see our earlier post in this series.

## Evaluate the Internal Network

The WAN gets the most attention, but the LAN is where plenty of VoIP deployments quietly fall apart. A packet's journey from the phone to the internet is only as good as the weakest link, and that link is often a $40 unmanaged switch hiding under someone's desk.

### Switches: Managed vs. Unmanaged

This is a binary question with major implications. Managed switches give you VLANs, QoS, port mirroring, and LLDP-MED for auto-provisioning phones. Unmanaged switches give you none of that.

If the client's network is built on unmanaged switches, you have a decision to make. You can deploy VoIP on a flat network with no traffic prioritization and hope for the best, or you can spec managed switches into the project. For anything beyond a five-person office, managed switches aren't optional. They're required.

Check the switch models, port counts, and age. A ten-year-old 100 Mbps switch is going to be a bottleneck even if everything else is perfect. You want gigabit ports at minimum.

### Power over Ethernet

Most modern VoIP phones are PoE-powered. Check whether the existing switches support PoE, and more importantly, whether they have enough power budget for the number of phones you're deploying.

A 24-port PoE switch might have a 190W power budget. If each phone draws 10-13W, that switch can realistically power 15-18 phones, not 24. Factor in any existing PoE devices (access points, cameras) that are already drawing from the budget. Running out of PoE capacity mid-deployment is an embarrassing problem to have.

If the switches don't support PoE, you'll need either new switches or midspan PoE injectors. Budget accordingly.

### VLAN Support

Can you segment voice traffic onto its own VLAN? This is one of the most effective things you can do for call quality. A voice VLAN isolates phone traffic from the broadcast storms, large file transfers, and general noise of the data network.

Most managed switches support 802.1Q VLANs. The question is whether the existing network design accommodates them. If the client is running a flat Layer 2 network with a single subnet, adding VLANs means reconfiguring the switching infrastructure and potentially the firewall/router.

It's worth it. A properly configured voice VLAN paired with [QoS policies](/blog/quality-of-service-explained) is one of the most reliable ways to protect call quality. We covered the mechanics of QoS in detail in that post, and it's worth reviewing before you design the VLAN and marking strategy.

### Cabling

Walk the site. Look at the patch panels, the cable runs, the wall jacks. What category of cabling is installed?

**Cat5e** is the minimum for VoIP. It supports gigabit Ethernet at distances up to 100 meters and handles PoE without issues. If the site is wired with Cat5e or better, you're fine.

**Cat5** (not 5e) is technically capable of gigabit at short distances, but it wasn't designed for it. If you find Cat5, test the runs you'll be using for phones. Marginal cabling works fine until it doesn't.

**Cat3** or older? That's a re-cable conversation. No amount of network configuration will compensate for cabling that can't reliably carry the traffic.

Check for obvious problems: cables running parallel to power lines (electromagnetic interference), patch cables that look like they've been chewed on, punch-downs that were done by someone in a hurry. Physical layer issues cause intermittent problems that are maddening to troubleshoot. Better to catch them now.

For a deeper look at [your local network and its impact on voice quality](/blog/your-local-network), see our dedicated post on the topic.

### WiFi Situation

Are any phones going to be on WiFi? Softphones on laptops? Mobile UC apps?

WiFi and real-time voice have a complicated relationship. The shared medium, contention-based access, and susceptibility to interference all work against the predictable, low-latency delivery that voice requires. We've covered this in detail in [wired vs. WiFi for VoIP](/blog/wired-vs-wifi-for-voip).

If WiFi voice is part of the plan, you need to assess the wireless infrastructure. What access points are deployed? Do they support WMM (WiFi Multimedia) for QoS? What's the channel utilization in the areas where people will be making calls? Are there neighboring networks causing co-channel interference?

For most MSP deployments, the recommendation is simple: hard-wire the desk phones, and accept that softphones on WiFi will have variable quality. Set that expectation with the client upfront.

### QoS Configuration

Is QoS configured on the existing network? If so, what's the policy? If not, can the equipment support it?

QoS is only useful if it's configured end-to-end. DSCP markings on voice packets need to be honored at every hop: from the phone, through the switches, through the firewall, and ideally by the ISP. A DSCP marking that gets stripped at the first switch isn't doing anything.

Check whether the firewall/router supports traffic shaping or prioritization on the WAN interface. This is where QoS matters most. Internally, on a properly provisioned gigabit network, congestion is rare. But on the WAN uplink, where bandwidth is constrained, QoS can be the difference between clean audio and [choppy, robotic sound](/blog/choppy-robotic-audio).

## Take Measurements

Opinions are nice. Data is better. Here's what to measure and how.

### Extended Ping and Jitter Tests

Run continuous ping tests to the VoIP provider's SBC or SIP proxy for at least 24 hours. Not five minutes. Twenty-four hours. You need to capture the full business cycle, including the afternoon utilization peak.

Use a tool that logs individual ping times so you can calculate jitter (the variation between consecutive ping times). A simple `ping -t` will give you round-trip times, but you'll need to post-process the data or use a tool that calculates jitter natively.

Better yet, run a dedicated [VoIP quality test](/tools/voip-test). Tools like VoIP Test give you MOS scores, jitter measurements, and packet loss data that are specifically relevant to voice quality. Generic speed tests tell you throughput; VoIP-specific tests tell you whether calls will sound good.

Run these tests from a device plugged into the network where phones will be deployed, ideally on the voice VLAN if one exists. Testing from the IT closet on a different subnet doesn't tell you what the phone on the sales floor will experience.

### iperf for Internal Throughput

Use iperf3 to test throughput between network segments. This helps identify internal bottlenecks: an oversubscribed uplink between floors, a dying switch, a duplex mismatch on a trunk port.

Set up an iperf server on one segment and run clients from others. Test with UDP traffic (which is what voice uses) at realistic rates. You're not trying to saturate the link; you're checking whether the internal network can deliver packets consistently at voice-traffic rates.

Pay attention to the jitter and packet loss numbers that iperf reports, not just the throughput. A link that delivers 900 Mbps with 2% packet loss is worse for voice than a link that delivers 100 Mbps with zero loss.

### Packet Loss Patterns During Business Hours

This is the measurement that catches problems the others miss. Packet loss is rarely constant. It tends to spike during periods of high utilization. You need to see what happens during the busiest parts of the business day, not just at 7 AM when nobody's there.

Log packet loss continuously for a full business week if possible. Three days at minimum. You're looking for patterns: does loss spike every day at 2 PM? Does it correlate with backup jobs? Does it happen when the office next door starts streaming video?

For a thorough understanding of what packet loss does to voice quality and why even small amounts matter, read our post on [understanding VoIP packet loss](/blog/understanding-voip-packet-loss). And for the jitter side of the equation, [what jitter is and why it matters](/blog/what-is-jitter-and-why-it-matters) covers the mechanics in detail.

## Interpreting the Results

Now you have data. Here's how to read it.

### The Three Buckets

**Will Work (Green Light)**
- Latency to VoIP provider: under 150 ms one-way (under 80 ms is ideal)
- Jitter: under 30 ms (under 15 ms is ideal)
- Packet loss: under 1% (under 0.5% is ideal)
- Sufficient upstream bandwidth with room to spare
- Managed switching with VLAN and QoS capability
- Cat5e or better cabling
- No sustained utilization spikes above 70%

If all of these check out, you're in good shape. Proceed with deployment planning.

**Needs Improvement (Yellow Light)**
- Latency between 150-250 ms
- Jitter between 30-50 ms
- Packet loss between 1-3%
- Upstream bandwidth is tight but manageable with QoS
- Mix of managed and unmanaged switches
- Some cabling concerns but not widespread

These sites can support VoIP, but not without remediation. The scope of the remediation depends on which metrics are yellow. High jitter with good bandwidth? QoS configuration might fix it. High latency? That's an ISP issue and you may need a different circuit. Packet loss during peak hours? Bandwidth upgrade or traffic shaping.

Present the findings to the client with specific recommendations and costs. "Your network can support VoIP, but we need to address X, Y, and Z first. Here's what that looks like."

**Going to Be a Problem (Red Light)**
- Latency over 250 ms
- Jitter over 50 ms
- Packet loss over 3%
- Insufficient upstream bandwidth even with QoS
- Unmanaged switches throughout, no VLAN capability
- Cat3 or degraded cabling
- Saturated WAN link during business hours

These sites need significant work before VoIP is viable. Be honest with the client. Deploying voice on a network that can't support it creates a terrible user experience and generates a flood of support tickets that will eat your margin.

The conversation here is: "We need to upgrade the network infrastructure before we can deploy VoIP. Here's the investment required." Some clients will accept that. Others will push back and ask you to deploy anyway. Hold the line. Your reputation is on the line every time a user picks up a phone and hears garbage audio.

### Context Matters

These thresholds aren't absolute. A call center with 50 concurrent calls has a much lower tolerance for network issues than a five-person office that makes 10 calls a day. Adjust your standards based on the client's use case, call volume, and tolerance for imperfection.

Also consider the VoIP platform. Some hosted providers are more forgiving of network imperfections than others. Some have built-in jitter buffers that handle moderate jitter gracefully. Others fall apart at the first sign of trouble. Factor in what you know about the platform when interpreting the results.

## Document Everything

Your assessment should produce a deliverable. A written report that captures:

- **Connection details**: ISP, circuit type, contracted speeds, measured speeds
- **Network topology**: Switch inventory, VLAN configuration, cabling assessment
- **Measurement results**: Latency, jitter, packet loss, bandwidth utilization (with graphs)
- **Findings**: What's good, what's concerning, what's a dealbreaker
- **Recommendations**: Specific actions required before deployment, with estimated costs
- **Risk assessment**: What happens if the client declines remediation

This document serves two purposes. First, it sets expectations. If the client declines to upgrade their cabling and later complains about call quality, you have a paper trail. Second, it demonstrates professionalism. Clients trust MSPs who do the homework before making promises.

## The Assessment as a Sales Tool

A thorough network assessment isn't just a technical exercise. It's a differentiator. Plenty of VoIP providers will ship phones to a site without ever checking whether the network can support them. When those deployments fail (and they will), the client blames the provider and starts looking for someone who does it right.

That someone is you. The MSP who walks in with a checklist, takes measurements, produces a report, and says "here's exactly what we need to do before go-live" wins the trust of the client. It takes more time upfront, but it prevents the avalanche of problems that come from deploying blind.

The assessment also creates opportunities. Need managed switches? You're selling hardware. Need a bandwidth upgrade? You're facilitating an ISP conversation. Need QoS configuration? That's billable engineering time. The assessment naturally surfaces the work that needs to be done, and positions you as the one to do it.

## Wrapping Up

The network assessment is the foundation of every successful VoIP deployment. Skip it and you're gambling. Do it thoroughly and you're making an informed decision backed by real data.

Walk the site. Check the connection. Inspect the switches. Test the cabling. Run the measurements for days, not minutes. Interpret the results honestly. Document everything. Then, and only then, commit to a deployment timeline.

Your clients are trusting you to get this right. The assessment is how you make sure you do.

*Next up: [Choosing the Right VoIP Platform for the Client](/blog/msp-choosing-voip-platform)*

---

### Part 5: Choosing the Right VoIP Platform for the Client

URL: https://voiptest.com/blog/msp-choosing-voip-platform
Published: 2026-03-21
Tags: msp, voip-platform, hosted-pbx, on-premises, platform-selection

*The MSP's Guide to VoIP: Part 5 of 20*

We all have a default. The platform we know inside and out, the one we can deploy in our sleep, the one whose quirks we have memorized. There is nothing wrong with having a go-to. The problem starts when every client gets that go-to regardless of whether it actually fits.

Choosing a VoIP platform for a client is not about what you are most comfortable supporting. It is about what serves that particular business best given their size, their workflows, their compliance obligations, and their budget. Sometimes the right answer is a hosted UCaaS seat. Sometimes it is an Asterisk box in a closet. Sometimes it is telling the client their current system is fine and they should stop looking for something new.

This article walks through the decision process from the client's perspective, not yours.

## Start With the Client, Not the Platform

Before you even open a vendor's pricing page, you need to understand the client. Not just how many phones they need, but how their business actually uses voice communication. Sit down with someone who answers the phone all day, not just the owner or the IT contact.

Here is what you need to map out before making any recommendation:

**Organization size and growth trajectory.** A five-person office that has been five people for a decade is different from a five-person startup planning to hire thirty people this year. The platform needs to fit today and tomorrow without requiring a forklift upgrade.

**Call volume and patterns.** Some businesses live on the phone. Call centers, medical offices, law firms with heavy client contact. Others might make ten calls a day and mostly use email. High call volume demands reliability and call quality in ways that light usage does not. Understanding call patterns also matters. A business with heavy morning call volume and dead afternoons has different capacity planning needs than one with steady traffic all day.

**Feature requirements.** Do they need an auto attendant? Call recording? A call center queue with reporting? CRM integration? Video conferencing built in? SMS? Fax? Make a list of what they actually use today and what they wish they had. Be specific. "We need call recording" might mean they record every call for compliance, or it might mean a manager occasionally wants to review a support interaction. For clients with complex call routing needs, sketching the flow in an [IVR planner](/tools/ivr-planner) during discovery helps surface requirements that a verbal conversation misses.

**Compliance and regulatory needs.** Healthcare clients need HIPAA-compliant call recording and messaging. Financial services clients may need Dodd-Frank compliant recording with tamper-proof storage, or MiFID II if they have EU or UK operations. Legal firms may need attorney-client privilege considerations around call recording policies. If compliance is in play, it narrows your options significantly and you cannot cut corners.

**IT sophistication on the client side.** Some clients have an internal IT person who can handle basic phone admin: adding users, changing call routing, updating a greeting. Others will call you every time someone new starts. This affects whether you recommend a platform with a simple admin portal or one that requires CLI knowledge to manage.

**Multi-site considerations.** A single-office business is straightforward. Multiple offices, remote workers, and hybrid arrangements all add complexity ([multi-site deployments](/blog/msp-multi-site-deployments) get their own guide). Can remote workers use softphones? Do branch offices need local survivability if the internet goes down? Does the receptionist need to see presence across all locations?

**Budget reality.** Not budget aspiration, budget reality. What are they spending today? What are they willing to spend? A hosted seat at twenty-five dollars per user per month is great until you multiply it by two hundred users and the client realizes that is sixty thousand dollars a year. On-prem has higher upfront cost but potentially lower ongoing cost at scale.

## The Hosted vs. On-Premises Decision Tree

Once you understand the client, the first major fork in the road is hosted versus on-premises. Here is how to think about it.

**Hosted (UCaaS) tends to be the right call when:**

- The client has fewer than fifty users (though this is not a hard cutoff)
- They want predictable monthly costs with no capital expenditure
- They have remote or hybrid workers who need the same experience as office workers
- They do not have and do not want to hire internal IT staff for phone management
- They need the platform to scale up or down quickly
- They want built-in redundancy without having to architect it themselves
- Their feature needs are mainstream: auto attendant, voicemail, basic call routing, maybe a small call queue

**On-premises tends to be the right call when:**

- The client has a large user count where per-seat pricing becomes expensive
- They have strict data sovereignty or compliance requirements that make cloud hosting complicated
- They need deep customization that hosted platforms do not offer
- They have reliable internal IT or an MSP (you) willing to commit to ongoing management
- They are in a location with unreliable internet and need the phone system to work during outages
- They have complex integrations with internal systems that require low-level API access
- Call volume is extremely high and per-minute or per-seat costs would be prohibitive

**The hybrid middle ground** is increasingly common: an on-premises system that connects to [SIP trunking](/blog/sip-trunking) services for external calling, or a hosted platform with local survivability appliances at each site. Do not think of it as binary.

## Evaluating Hosted Platforms

If you are going the hosted route, here is what to evaluate. And evaluate means actually testing, not just reading the marketing site.

### Reliability Track Record

Ask for uptime numbers, but also check independent sources. Search for outage reports. Ask the vendor what happened during their last major outage and what they changed afterward. A vendor that claims 99.999% uptime but had a four-hour nationwide outage last quarter is not being straight with you.

Look at their architecture. Do they have geographically distributed data centers? What happens if one region goes down? Do they have a published status page with historical incident data?

### Feature Set

Map the client's requirements list against the platform's actual capabilities. Do not trust the feature comparison matrix on the vendor's website, because those are designed to make every box look checked. Get a trial account and test the specific features the client needs.

Pay special attention to how the platform handles [SIP](/blog/what-sip-actually-is) and [media negotiation](/blog/sdp-media-negotiation). Some hosted platforms use proprietary protocols between their endpoints and translate to SIP only at the edge. This can cause compatibility issues with third-party devices and SIP trunks.

### API Availability and Integration Ecosystem

If the client needs CRM integration, check whether the platform has a native integration or just a webhook that requires custom development. Native Salesforce integration that syncs call logs automatically is different from a generic webhook that fires on call events and requires you to build the rest.

Look at the API documentation. Is it well-documented? Is there a sandbox environment? Are there rate limits that would be a problem? A good API is a sign that the vendor takes the platform seriously as a business tool, not just a phone service.

### Support Quality

This matters more than most MSPs realize, because when something goes wrong at 2 AM and you cannot fix it yourself, vendor support is your lifeline. Test the support experience during your evaluation. Open a ticket with a moderately technical question and see how long it takes to get a useful response. Try their phone support. Ask to speak with someone from their partner engineering team, not just tier-one support.

Some vendors have dedicated MSP/partner support channels that are dramatically better than their end-user support. If those exist, make sure your partnership tier includes access.

### Pricing Model

Hosted platform pricing generally falls into a few categories:

**Per seat, flat rate.** You pay a fixed amount per user per month and get unlimited domestic calling. Simple to budget, but can be expensive at scale. Watch for what is included versus add-on, since some vendors charge extra for call recording, call queues, or analytics.

**Per seat plus per minute.** Lower per-seat cost but you pay for call minutes. This works for light-usage businesses but can get expensive for heavy callers. Make sure you understand whether inbound, outbound, or both are metered.

**Blended or tiered.** Different user tiers at different price points: a basic user who just needs a phone, a standard user with voicemail and basic features, a power user with call center capabilities. This can save money if the client has a mix of usage patterns, but it adds billing complexity.

**Contract terms** matter too. Month-to-month gives flexibility but usually costs more. Annual contracts lock in pricing but create switching costs. Multi-year contracts with aggressive discounts can trap you if the platform does not work out. Push for annual with a meaningful out clause rather than multi-year.

## Evaluating On-Premises Platforms

If the decision tree points toward on-prem, you have a different set of choices to make.

### Open Source: Asterisk vs. FreeSWITCH

**Asterisk** is the grandfather of open-source telephony. Massive community, enormous ecosystem, well-understood. If you are building a traditional PBX with standard call routing, voicemail, IVR, and conference bridges, Asterisk is proven. FreePBX provides a web GUI on top of Asterisk that makes administration manageable for most common tasks.

The trade-off is that Asterisk's architecture shows its age in some areas. It was designed as a PBX first and a general-purpose telephony engine second. High-density call processing and complex media manipulation can push its limits.

**FreeSWITCH** is more of a telephony engine than a PBX out of the box; [the project describes itself as a telecom stack](https://github.com/signalwire/freeswitch). It handles high call volumes more efficiently than Asterisk in many scenarios and has a more modern architecture for media processing. But it requires more expertise to deploy and configure. The community is smaller. Finding a FreeSWITCH consultant is harder than finding an Asterisk consultant.

Choose Asterisk if the client needs a PBX and you want a large support community. Choose FreeSWITCH if you need high-density call processing, a SBC, or a platform for custom telephony applications.

### Commercial On-Premises

**3CX** has become a popular choice for MSPs because it is relatively easy to deploy and manage. It runs on Linux or Windows, supports a wide range of SIP phones, and includes a decent web client and mobile apps. Licensing is by simultaneous calls, subject to a maximum extension count per tier, which can still be cost-effective for businesses where not everyone is on the phone at the same time. The downside is that you are dependent on 3CX's licensing model and roadmap, and they have made significant licensing changes in the past that caught partners off guard.

**Grandstream UCM series** is a hardware appliance approach. Relatively inexpensive, straightforward to deploy for small to mid-size businesses. The UCM6304, for example, handles up to 2000 users and 300 concurrent calls (200 with SRTP), per <a href="https://documentation.grandstream.com/knowledge-base/ucm630x-series-user-manual/" rel="nofollow noopener noreferrer" target="_blank">Grandstream's published UCM630x capacity table</a>. The limitation is that you are locked into Grandstream's firmware update cycle and feature set. Customization beyond what the GUI offers is limited.

**Other commercial options** like Sangoma (which now owns FreePBX and offers commercial modules), Yeastar, and Zultys each have their niches. Evaluate them the same way: test actual features, check the support experience, understand the licensing model, and make sure the platform can grow with the client.

### Hardware and Infrastructure Requirements

On-premises means you are responsible for hardware. For a small deployment, a modest server or even a virtual machine will do. For larger deployments, consider:

- Redundant power supplies and UPS
- RAID storage for call recordings
- Adequate CPU and RAM for concurrent call capacity (with headroom for growth)
- Network interface redundancy
- A maintenance contract for hardware failures

If the client does not have a proper server room with climate control and backup power, an on-prem phone system is going to have reliability problems that no amount of software configuration can fix.

### Ongoing Maintenance Commitment

This is where many MSPs underestimate the on-prem burden. You are committing to:

- Security patches and firmware updates
- Certificate renewals for TLS/SRTP
- Monitoring for service health and call quality
- Backup and disaster recovery testing
- Capacity planning as the client grows
- Meeting MLTS 911 obligations: direct 911 dialing, on-site notification, and dispatchable location under Kari's Law and RAY BAUM'S Act bind whoever installs, manages, or operates the system
- Troubleshooting codec issues, [SIP registration problems](/blog/what-sip-actually-is), and one-way audio
- Staying current with the platform's development roadmap so you are not caught off guard by breaking changes

Build these ongoing costs into your managed services agreement. If you are charging a flat monthly fee for phone system management, make sure it reflects the actual time you will spend. Too many MSPs sell on-prem phone systems at a healthy project margin and then lose money maintaining them for years afterward.

## When to Recommend Keeping the Existing System

This might be the most important section in this article. Sometimes the right recommendation is to leave things alone.

**The current system works and meets their needs.** If the client has a phone system that is functioning, their users are not complaining, and it does everything the business requires, there is no reason to replace it just because it is old or because you do not support that platform. Help them maintain it or find someone who can.

**The switching costs outweigh the benefits.** Every migration has costs beyond the price of the new system: user retraining, temporary productivity loss, number porting delays, integration rework, and the inevitable problems that surface in the first few weeks. If the new system's benefits are marginal, those switching costs may not be justified.

**The client is in a transitional period.** If they are about to move offices, go through a merger, or significantly change their workforce size, now is a bad time to deploy a new phone system. Wait until the dust settles and you can size the solution properly.

**Their real problem is not the phone system.** Sometimes clients blame the phone system for issues that are actually network problems, internet bandwidth limitations, or SIP trunking configuration issues. Before recommending a platform replacement, do the diagnostic work to identify the actual root cause. A new platform sitting on the same bad network will have the same problems.

**You cannot adequately support the replacement.** If the best platform for this client is one you have no experience with and no bandwidth to learn, recommending it and then struggling to support it helps nobody. Either partner with someone who has the expertise, invest in training before the deployment, or be honest that this particular project is not a fit for your shop.

## Building Your Evaluation Framework

Rather than evaluating platforms ad hoc for every client, build a repeatable framework:

1. **Client discovery questionnaire.** Standardize the questions you ask every prospect. Cover all the factors listed above: size, call volume, features, compliance, IT sophistication, multi-site, budget. Write it down so you do not forget anything and so every technician in your shop asks the same questions.

2. **Platform scoring matrix.** Create a weighted scorecard that maps client requirements to platform capabilities. Weight the scores based on what matters most to this specific client. Compliance support might be heavily weighted for a healthcare client and irrelevant for a retail shop.

3. **Reference deployments.** Maintain a list of your own successful deployments by platform and client profile. When a new prospect matches a profile you have already served, you can draw on that experience and potentially reference the existing client.

4. **Total cost of ownership calculator.** Build a spreadsheet that models three-year and five-year TCO for hosted versus on-prem, including your labor costs for ongoing management. Show the client real numbers, not guesses.

5. **Migration playbook.** For each platform you support, document the migration process step by step. This reduces the risk of the deployment going sideways and lets you give the client a realistic timeline.

Your platform choice affects your regulatory position. Before committing to a platform and service model, understand your FCC obligations as described in Parts 17 through 20 of this series. The difference between reselling a hosted platform under a wholesale provider's authority and deploying your own PBX with direct trunking has significant regulatory implications (the [MLTS direct 911 dialing rules under 47 CFR 9.16](https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-9/subpart-F/section-9.16) are one concrete example) that should factor into your evaluation. Consult a telecom attorney before signing any wholesale or trunking agreement.

## Avoiding the Comfort Zone Trap

The temptation to recommend what you know is strong, and it is not entirely irrational. You can deploy a familiar platform faster, support it better, and troubleshoot it more efficiently. All of that matters.

But it does not matter as much as getting the client the right solution. A platform you can deploy in four hours that does not meet the client's needs is worse than one that takes two weeks but actually works for them.

The way to reconcile this tension is to build depth in two or three platforms that cover different client profiles. Maybe you have a hosted UCaaS platform for small to mid-size clients with standard needs, an on-prem solution for larger or compliance-heavy clients, and the ability to support clients who want to keep their existing system. You do not need to be an expert in everything, but you need enough range to match the right tool to the job.

If a client's needs fall outside your range, the professional move is to say so and help them find someone who can serve them. That honesty builds more trust than forcing a square peg into a round hole and hoping they do not notice.

## The Recommendation Conversation

When you present your recommendation to the client, walk them through your reasoning. Show them the decision tree, not just the conclusion. Explain why hosted makes sense for them, or why on-prem is the better fit, or why their current system deserves to stay.

Clients who understand the reasoning behind a recommendation are more confident in the decision, more patient during deployment, and more likely to refer you to others. Clients who are just told "you should use Platform X" without context will second-guess the choice at the first sign of trouble.

Be transparent about trade-offs. Every platform has downsides. If you pretend otherwise, you lose credibility when those downsides surface. If you name them upfront, the client is prepared and you look honest.

The goal is not to sell a phone system. The goal is to solve a communication problem in a way that makes the client's business work better. Sometimes that is a shiny new UCaaS deployment. Sometimes it is a firmware update on the box they already have. Either way, you did the right work and made the right call.

*Next up: [The Internet Connection Conversation](/blog/msp-internet-connection-conversation)*

---

### Part 6: The Internet Connection Conversation

URL: https://voiptest.com/blog/msp-internet-connection-conversation
Published: 2026-03-21
Tags: msp, internet-connection, bandwidth, client-communication, isp

*The MSP's Guide to VoIP: Part 6 of 20*

There is a conversation that every MSP dreads. You have finished your assessment, you have run the numbers, and you are sitting across from a client who is excited about moving to VoIP. And you have to tell them their internet connection cannot support it.

This is one of the most delicate moments in a VoIP project. Get it right and you build trust, set realistic expectations, and lay the groundwork for a successful deployment. Get it wrong and you sound like you are padding the invoice, pushing unnecessary upgrades, or stalling a project the client is eager to start.

This guide is about navigating that conversation with honesty, clarity, and a focus on business outcomes rather than technical specifications.

## Why This Conversation Matters

Most clients do not think about their internet connection in terms of voice quality. They think about it in terms of whether web pages load and whether email arrives. If those things work, the internet is "fine." Telling them it is not fine, specifically for voice, requires you to bridge a knowledge gap without being condescending.

The stakes are real. If you deploy VoIP on an inadequate connection, calls will sound terrible. The client will blame the phone system, blame you, and possibly blame VoIP as a technology. You will spend months troubleshooting problems that were predictable from day one. Understanding [why voice traffic is uniquely demanding](/blog/why-voice-is-hard) is the foundation of this entire conversation.

On the other hand, if you insist on a connection upgrade that the client sees as unnecessary or too expensive, you risk losing the project entirely, or worse, losing the client relationship.

The goal is to present the situation accurately, frame the upgrade as a prerequisite rather than an upsell, and give the client options that respect their budget and timeline.

## Assessing What They Have

Before you can have the conversation, you need to know exactly what you are working with. This means more than running a speed test.

**Connection type matters more than speed.** A 100 Mbps cable connection and a 100 Mbps fiber connection are not equivalent for voice. The cable connection shares bandwidth with neighbors, has asymmetric speeds, and may have unpredictable latency spikes during peak hours. The fiber connection offers symmetric speeds, consistent latency, and dedicated capacity. Both say "100 Mbps" on the invoice, but they will deliver very different voice experiences.

For a thorough understanding of how different connection types affect voice, review the detailed breakdowns for [fiber](/blog/fiber-internet), [cable](/blog/cable-internet), [DSL](/blog/dsl-connection), and [fixed wireless](/blog/fixed-wireless). Each has distinct characteristics that matter for real-time communication.

**Measure during business hours.** Weekend speed tests are meaningless. You need to understand what the connection looks like at 10 AM on a Tuesday when the entire office is working. Jitter, latency, and packet loss during peak usage hours are the numbers that predict voice quality. A browser-based [VoIP quality test](/tools/voip-test/msp) the client can run from their own desk makes this measurement a two-minute email instead of a site visit.

**Account for existing traffic.** The client's internet connection is not sitting idle waiting for voice traffic. It is handling email, web browsing, cloud applications, file syncs, video conferencing, and whatever else the business runs. Voice needs its share of capacity on top of everything else.

**Check the contract, not just the speed.** Many business internet contracts include language about best-effort delivery, contention ratios, or fair-use policies. A connection that advertises 50 Mbps may only guarantee 10 Mbps. That guaranteed floor is what matters for voice.

## Framing the Conversation

When you sit down with the client, resist the urge to lead with technical details. Nobody makes budget decisions based on jitter measurements. Instead, frame everything in terms of business outcomes.

### Do Not Say This

"Your connection has 47 milliseconds of jitter and 2.3 percent packet loss during peak hours, which exceeds the acceptable threshold for G.711 codec operation."

### Say This Instead

"When your team is busy during normal working hours, your current internet connection gets congested. Think of it like a two-lane road during rush hour. Email and web browsing handle that congestion fine because they can wait a fraction of a second and retry. Voice calls cannot wait. When a voice call hits that congestion, you hear choppy audio, words cutting out, and delays that make it hard to have a natural conversation. Your current connection does not have enough reliable capacity to add voice traffic on top of everything your team already uses it for."

The key principles:

- **Use analogies the client already understands.** Roads, pipes, and lanes are intuitive. Codec specifications are not.
- **Connect to their daily experience.** If they have ever had a bad video call where audio cut out, reference that. It is the same underlying problem.
- **Be specific about the consequence.** Not "it might have issues" but "your team will experience choppy calls and missed words during the busiest parts of the day, exactly when call quality matters most."

## Connection Types: A Business-Oriented Summary

When discussing options with clients, you do not need to explain the physics of each connection type. You need to explain what each one means for their daily operations.

**Fiber** is the gold standard for voice. It provides the same speed in both directions, consistent performance regardless of time of day, and handles voice traffic alongside everything else without breaking a sweat. For a deeper look, see the [fiber guide](/blog/fiber-internet). If fiber is available at the client's address, it is almost always the right answer for a business running VoIP.

**Cable** can work for voice, but it comes with caveats. The upload speed is typically much lower than the download speed, and performance can vary throughout the day because capacity is shared with other businesses and residences in the area. For smaller offices with moderate call volumes, cable can be adequate, especially with proper [QoS configuration](/blog/msp-network-preparation). For larger deployments or call-heavy businesses, it is a gamble. The [cable internet breakdown](/blog/cable-internet) covers the specifics.

**DSL** is increasingly marginal for modern VoIP deployments. Speed depends heavily on the physical distance from the provider's equipment, and bandwidth is often too limited for voice alongside other business traffic. It can work for very small offices with minimal concurrent calls, but it is rarely the right foundation for a VoIP project. See the [DSL guide](/blog/dsl-connection) for more detail.

**Fixed wireless** varies enormously by provider and location. Some fixed wireless services deliver fiber-like performance. Others are essentially overloaded cellular towers that struggle with real-time traffic. Weather can also affect performance. This one requires careful, location-specific evaluation. The [fixed wireless overview](/blog/fixed-wireless) helps you assess what you are actually getting.

For a structured approach to weighing these options, the [ISP selection guide](/blog/how-to-choose-isp) walks through the evaluation process. And once you are comparing actual proposals, the [guide to reading ISP quotes](/blog/reading-isp-quote) will help you cut through the marketing language.

Understanding the [foundational role your ISP plays](/blog/isp-foundation) in overall VoIP quality is essential context for these conversations. It is not an optional upgrade. It is the platform everything else depends on.

## When an Upgrade Is a Prerequisite

There is a difference between "an upgrade would be nice" and "this project cannot succeed without an upgrade." Be honest about which situation you are in.

**An upgrade is a prerequisite when:**

- Current measured performance (not advertised speeds) cannot support the planned number of concurrent calls plus existing traffic with any reasonable margin.
- The connection type is fundamentally unsuitable. A shared residential cable line for a 30-seat call center, for example, will not work.
- Measured packet loss or jitter during business hours already exceeds acceptable thresholds before adding any voice traffic.
- The connection has no service level agreement and the provider offers no guarantees about performance.

**An upgrade is a strong recommendation (but not a hard prerequisite) when:**

- Current performance is technically adequate but leaves very little headroom for growth or traffic spikes.
- The connection type is workable but not ideal, and the client's business depends heavily on call quality.
- You can make it work with aggressive QoS and traffic management, but the margin for error is thin.

Be direct about which category the client falls into. If it is a prerequisite, say so clearly: "I would not be doing my job if I deployed this system on your current connection. The calls will sound bad, your team will be frustrated, and we will both spend time troubleshooting a problem we could have prevented."

That is not an upsell. That is professional responsibility.

For businesses where voice quality is mission-critical, [dedicated internet access](/blog/dedicated-internet-access) may be worth exploring. It is more expensive, but it comes with guarantees that shared connections cannot match.

## The Backup Connection Question

Backup internet connections come up in nearly every VoIP conversation, and the answer is not always the same. Here is how to think about it honestly.

**A backup connection is genuinely necessary when:**

- The business has a single internet connection and depends on phone service to operate. A medical office, a sales team, a support center. If the phones go down and revenue stops or patients cannot reach you, a backup connection is not optional.
- The primary connection has a history of outages or the provider's uptime record is poor.
- The business has compliance or contractual obligations that require communication availability.

**A backup connection is nice to have (but not essential) when:**

- The business has multiple ways to communicate during a short outage. Cell phones, email, and a "we will call you back" message can bridge a few hours.
- The primary connection is highly reliable with a strong SLA and a track record to match.
- The business can tolerate occasional brief interruptions without significant financial or operational impact.

Be honest with yourself and the client about which category they fall into. Recommending a $200/month backup circuit to a five-person office that could survive on cell phones for a few hours is hard to justify. Recommending one to a 50-seat sales floor where every hour of downtime costs thousands in lost deals is common sense.

The [redundancy and failover guide](/blog/redundancy-failover) covers the technical architectures in detail. Use it to design the right solution once the client has decided a backup makes sense for their situation.

## When the Budget Does Not Stretch

Here is where the conversation gets hardest. You have assessed the connection, you know it is not adequate, and the client either cannot afford or does not want to pay for an upgrade. What do you do?

First, acknowledge the constraint honestly. Do not pretend the current connection will work if it will not. That path leads to a failed deployment, a frustrated client, and damage to your reputation.

Instead, present options.

### Option 1: Delay the Deployment

Sometimes the timing is not right. If the client's lease is up in six months and they are moving to a building with better connectivity, it may make sense to wait. If their ISP contract is renewing soon and better options will be available, a few months of patience can save significant money.

Frame this positively: "Let's get the right foundation in place first so that when we do deploy, it works perfectly from day one."

### Option 2: Start With Fewer Seats

If the connection can support some VoIP traffic but not the full deployment, consider a phased approach. Start with the roles that benefit most from VoIP (the reception desk, the sales team, the executives who travel) and keep everyone else on the existing system temporarily.

This lets the client experience the benefits of VoIP, builds internal momentum for the upgrade, and gives them time to budget for the connection improvement needed to expand.

### Option 3: Find Compromises in the Connection

Sometimes there are middle-ground options between the current connection and the ideal one. A modest upgrade from a 25/5 Mbps cable plan to a 100/20 Mbps business plan might cost only an extra $50 to $100 per month and provide enough headroom. Adding a lower-cost secondary connection for failover might be more palatable than upgrading the primary.

Explore what is actually available at the client's address. Availability varies enormously by location, and sometimes a better option exists that the client simply has not been offered. Call the ISPs. Check the service maps. Ask about business-class tiers that may not be prominently advertised.

### Option 4: Optimize What You Have

If an upgrade is truly impossible in the near term, you can sometimes squeeze acceptable performance from a marginal connection through aggressive network optimization. Dedicated VLANs for voice, strict QoS policies, traffic shaping to limit bandwidth-hungry applications during business hours. These measures can create enough protected capacity for a limited VoIP deployment.

Be clear with the client that this is a compromise, not a solution. Set expectations explicitly: "We can make this work for your core phone needs, but call quality will not be as consistent as it would be on a better connection, and we will not have room to add more lines or features without addressing the underlying connection."

### Option 5: Rethink the Scope

Sometimes the answer is to adjust the VoIP project itself. Instead of a full-featured deployment with video conferencing, call recording, and advanced call routing, start with basic phone service that uses less bandwidth. Scale the project to fit the infrastructure rather than the other way around.

## Evaluating What Is Available

One of the most valuable things you can do for a client is research what connectivity options actually exist at their address. This is not something most business owners know how to do effectively, and the information is not always easy to find.

**Check multiple providers.** The client's current ISP may not offer the best option for their address. Fiber availability, in particular, varies block by block in many cities.

**Ask about business tiers.** Residential and business services at the same address can be dramatically different. Business tiers often include static IPs, SLAs, faster repair times, and more consistent performance, all of which matter for voice.

**Consider the timeline.** ISPs are constantly expanding their networks. Fiber that was not available six months ago may be available now, or may be coming in the next quarter. A quick call to the provider's business sales team can reveal options that the website does not show.

**Look at the physical infrastructure.** If the building already has fiber run to it for another tenant, getting service connected may be faster and cheaper than a new installation. If the building is in a business park, there may be options that residential neighborhoods lack.

**Get actual quotes.** Comparing advertised pricing to actual quotes is essential. The [guide to reading ISP quotes](/blog/reading-isp-quote) will help you decode what providers are actually offering versus what their marketing suggests.

## Documenting the Recommendation

Whatever the outcome of the conversation, document it. Put your assessment and recommendation in writing. Not as a CYA exercise, but as a professional practice that protects both you and the client.

Your documentation should include:

- **Current connection details.** What they have, what it actually delivers during business hours, and where it falls short.
- **Your recommendation.** What connection would properly support the planned deployment.
- **The options you discussed.** Including costs, timelines, and trade-offs for each.
- **The client's decision.** What they chose to do and any limitations they accepted.
- **Expected outcomes.** What voice quality the client should expect given their chosen path.

If the client decides to proceed on a connection you have flagged as inadequate, that documentation becomes critical. Not as ammunition to say "I told you so," but as a reference point when quality issues arise. It shifts the conversation from "why does this sound terrible?" to "this is the trade-off we discussed, and here's what we can do to improve it."

## The Long Game

The internet connection conversation is not a one-time event. Connections change, businesses grow, and what was adequate two years ago may not be adequate today. Build connection assessment into your regular review cadence with clients.

As you add seats, enable new features, or see the client's overall internet usage grow, revisit the capacity question. A proactive "your connection is starting to get tight, let's plan an upgrade before it affects call quality" is a much better conversation than a reactive "your calls sound bad because your connection is overloaded."

This is also where your ongoing monitoring and testing tools become essential. Regular testing gives you data to back up these conversations: not opinion, not intuition, but measured performance over time.

## Bringing It Together

The internet connection conversation is fundamentally about trust. You are asking a client to spend money on something they may not fully understand, based on your professional judgment. The way you handle this conversation either builds or erodes the trust that your entire client relationship depends on.

Be honest about what you find. Be clear about the consequences. Frame upgrades as prerequisites when they genuinely are, and be equally honest when they are merely nice to have. Respect the client's budget by presenting options, not ultimatums. And document everything so that both you and the client have a shared understanding of the path forward.

The clients who trust you most are not the ones who never heard bad news from you. They are the ones who heard bad news delivered honestly, with clear options and a genuine focus on their business outcomes.

Before proceeding further in your voice deployment, make sure you understand the regulatory obligations that come with offering voice services. Parts 17 through 20 of this series cover FCC registration, STIR/SHAKEN, and the Robocall Mitigation Database. These are not optional and the consequences of non-compliance are severe.

*Next up: [Network Preparation: VLANs, QoS, and the Foundation Work](/blog/msp-network-preparation)*

---

### Part 7: Network Preparation: VLANs, QoS, and the Foundation Work

URL: https://voiptest.com/blog/msp-network-preparation
Published: 2026-03-22
Tags: msp, vlan, qos, network-configuration, firewall, voip-deployment

*The MSP's Guide to VoIP: Part 7 of 20*

You have assessed the client's network. You have chosen a platform. You have had the internet conversation and whatever upgrades were needed are either in place or ordered. Now comes the part where you actually prepare the network for voice traffic, and this work should be finished before the first phone arrives on site.

The difference between a voice deployment that works cleanly from day one and one that generates tickets for the next three months almost always comes down to what happens in this step. Rushing through network preparation to get phones on desks faster is one of the most common mistakes MSPs make with voice deployments, and it is one of the most expensive to fix after the fact.

## The voice VLAN

If there is one thing you take from this post, let it be this: voice traffic should be on its own VLAN. This is not optional for any deployment beyond a handful of phones in a very small office.

A voice VLAN gives you four things that matter.

**Traffic isolation.** Voice packets and data packets travel on logically separate networks. A large file transfer between two workstations does not compete with voice traffic at the switch level. A broadcast storm on the data network does not take down the phones. The two networks coexist on the same physical switches but cannot interfere with each other.

**QoS enforcement.** With voice on its own VLAN, you can apply QoS policies specifically to voice traffic. The switch can prioritize everything on the voice VLAN without needing to inspect each packet to determine what it is. This is simpler to configure and more reliable than trying to identify voice traffic by DSCP markings alone.

**Security.** Phones on a separate VLAN cannot be reached directly from devices on the data VLAN without passing through a router or layer 3 switch, which means you can apply access control rules between the two. This reduces the attack surface and prevents compromised workstations from directly accessing phone configuration interfaces.

**Troubleshooting simplicity.** When a call quality problem occurs, you can immediately determine whether the issue is internal to the voice network or external. If the voice VLAN is clean (no errors, no congestion, no drops), the problem is upstream of the switch. This saves hours of diagnostic time compared to trying to untangle voice and data traffic on a flat network.

### Setting up the VLAN

The general process works the same regardless of switch vendor. Create a new VLAN and assign it an ID. Convention varies, but VLAN 100 for voice is common. Give it a descriptive name. Configure each switch port that connects to a phone as a trunk or voice port that carries both the voice VLAN (tagged) and the data VLAN (untagged). The phone uses the voice VLAN for its own traffic and passes the computer's traffic through on the data VLAN.

Most IP phones discover their VLAN assignment automatically through LLDP-MED or CDP. You configure the voice VLAN on the switch port, and the phone picks it up during boot. Some environments use DHCP options to communicate the VLAN ID to the phone instead.

On the routing side, you need inter-VLAN routing so that the voice VLAN can reach the internet (for hosted VoIP) or the PBX server (if it sits on a different VLAN). This is typically handled by the main router or a layer 3 switch. Configure a gateway address for the voice VLAN subnet and ensure routing between the voice and data VLANs is in place, with appropriate firewall rules between them.

### IP addressing

The voice VLAN gets its own subnet. If your data network is on 192.168.1.0/24, put voice on something like 10.10.10.0/24. Keeping the subnets distinct makes firewall rules, [QoS policies](/blog/quality-of-service-explained), monitoring, and troubleshooting straightforward because you can identify traffic by its source subnet.

Size the subnet for growth. A /24 gives you 254 usable addresses, which is more than enough for most deployments. Even if the client has 50 phones today, the overhead of a /24 is zero and it means you will not need to re-subnet later.

## QoS configuration

With the voice VLAN in place, QoS becomes straightforward. The goal is to ensure that voice packets are always prioritized over data traffic, particularly at the points where congestion is most likely to occur.

### On the switches

Configure the switch to trust DSCP markings from devices on the voice VLAN. Most VoIP phones mark their packets with [DSCP 46 (Expedited Forwarding)](https://www.rfc-editor.org/rfc/rfc4594.html) by default. The switch should place these packets into a strict priority queue so they are forwarded before any other traffic.

If the switch supports it, configure it to remark any traffic on the voice VLAN that is not already marked with DSCP 46. This provides a safety net in case a phone's DSCP configuration gets changed or a device on the voice VLAN sends unmarked traffic.

On ports that connect to the data VLAN, you can optionally set DSCP 0 (best effort) for all traffic to prevent data devices from marking their traffic as high priority and bypassing the QoS system.

### On the router

This is where QoS has the most impact, because the router is the bottleneck where your gigabit internal network meets the client's internet connection. Configure the router's outbound interface (the WAN-facing interface) with a QoS policy that does the following:

Create a strict priority queue for traffic marked with DSCP 46. Reserve bandwidth for this queue based on the maximum number of concurrent calls expected, plus a margin. Each G.711 call uses 80 kbps in each direction at the IP layer, or 87.2 kbps once Ethernet framing is counted at 20 ms packetization. Always check which layer a figure describes, and size a WAN reservation against that link's own overhead rather than Ethernet's. You can use a [Bandwidth Calculator](/tools/bandwidth-calculator) to size the reservation precisely for the client's codec and call volume. If the client expects a maximum of 20 concurrent calls, reserve at least 2 Mbps of upload bandwidth for the priority queue.

Cap the priority queue to prevent it from consuming all available bandwidth in an abnormal situation. A cap of 30 to 40 percent of the total upload bandwidth is a reasonable starting point.

Assign remaining traffic to a best-effort queue that gets whatever bandwidth is left after the priority queue is served.

For a detailed treatment of how QoS works at a conceptual level, including the different queuing strategies and their trade-offs, see the [QoS post](/blog/quality-of-service-explained) in the VoIP From the Ground Up series.

## Firewall configuration

VoIP requires specific ports and protocols to be allowed through the firewall. Get any of these wrong and calls will either fail to connect or connect with no audio.

### SIP signaling

SIP signaling typically uses UDP port 5060 or TCP/TLS port 5061. The exact ports depend on the VoIP provider or PBX configuration. Allow outbound traffic from the voice VLAN to the provider's SIP servers on the appropriate ports. For hosted platforms, the provider will document the specific IP addresses and ports to allow.

### RTP media

RTP audio uses a range of UDP ports. The range varies by configuration but is commonly something like 10000 to 20000, or 16384 to 32768. This is a wide range because each call uses a dynamically assigned port within the range. Allow outbound and inbound UDP traffic on this range between the voice VLAN and the provider's media servers.

For on-premises PBX deployments, the RTP port range is configured on the PBX and should be as narrow as practical while still accommodating the maximum number of concurrent calls (each call uses two ports per endpoint, one for RTP audio and one for RTCP control).

### SIP ALG

Turn it off. SIP ALG (Application Layer Gateway) is a feature on many routers that attempts to modify SIP messages as they pass through NAT. The intention is to fix the NAT traversal issues that SIP inherently has. In practice, most SIP ALG implementations are buggy and cause more problems than they solve: corrupted headers, failed registrations, [one-way audio](/blog/one-way-audio), and random call drops.

Every major VoIP provider and PBX vendor recommends disabling SIP ALG. The mechanisms that modern VoIP systems use to handle NAT (STUN, registration keep-alives, and SIP outbound proxy) work correctly without SIP ALG and break when SIP ALG interferes with the messages.

Finding the SIP ALG setting varies by router manufacturer. It might be called SIP ALG, SIP Passthrough, SIP Transformations, or SIP Helper. Some routers bury it in an advanced NAT configuration section. Some require a CLI command to disable it. Check the manufacturer's documentation for the specific router model. For the full technical explanation of why NAT and SIP interact poorly, see the [NAT traversal post](/blog/sip-nat-traversal).

### NAT considerations

Ensure the router's NAT timeout for UDP connections is at least 120 seconds, and preferably 300 or more. That is not just a comfortable margin: [RFC 4787](https://www.rfc-editor.org/rfc/rfc4787.html) requires that a NAT UDP mapping not expire in under two minutes and recommends five minutes or more, so anything shorter is a router that does not meet the standard. SIP registrations use UDP, and if the NAT entry for a phone's registration expires before the phone sends its next keep-alive, the phone becomes unreachable for inbound calls. Most phones send keep-alive packets every 30 seconds by default, but if the NAT timeout is shorter than the keep-alive interval, the phone will intermittently lose connectivity.

## DHCP for the voice VLAN

The voice VLAN needs its own DHCP scope with settings tailored for phones. At minimum, configure:

**IP address range and subnet mask.** Standard DHCP pool configuration for the voice VLAN subnet.

**Default gateway.** The router or layer 3 switch interface for the voice VLAN.

**DNS servers.** Reliable DNS is important for VoIP because phones and PBX systems often use hostnames to reach SIP servers. If DNS resolution is slow or unreliable, phones will experience registration delays and call setup failures.

**[Option 66 (TFTP server name)](https://www.rfc-editor.org/rfc/rfc2132.html).** This tells the phone where to download its configuration file. For auto-provisioning, this is the name or URL of the provisioning server, which might be hosted by the VoIP provider, running on the PBX, or on a separate provisioning appliance on the network.

**Option 67 (boot file name).** Some phones use this to determine which configuration file to request from the provisioning server.

**Option 150 (TFTP server address).** Where option 66 carries a name, option 150 carries one or more IPv4 addresses, and takes priority over option 66 when both are present. Cisco phones look for it specifically, and a scope that sets only one of the two is a common cause of half a deployment provisioning and half not.

**NTP server (option 42).** Phones need accurate time for call logs, voicemail timestamps, and display. Pointing them to a reliable NTP server ensures consistent timekeeping across all devices.

The specific DHCP options required depend on the phone manufacturer and the provisioning method. Polycom, Yealink, Grandstream, and Cisco phones each have their own provisioning expectations. Consult the phone manufacturer's deployment guide for the exact options needed.

## Testing the prepared network

Before any phones arrive, verify that the network preparation is correct.

**VLAN verification.** Connect a laptop to a voice port and verify it receives an IP address from the voice VLAN DHCP scope. Verify it can reach the internet through the voice VLAN gateway. Verify it can reach the VoIP provider's SIP servers.

**QoS verification.** Generate traffic from the voice VLAN and verify that it is being prioritized at the router's outbound interface. Some routers show queue statistics that let you confirm traffic is hitting the priority queue.

**Firewall verification.** From a device on the voice VLAN, test connectivity to the VoIP provider's SIP servers on the appropriate ports. A simple telnet or nc test to the SIP port confirms the firewall is allowing traffic through.

**DHCP verification.** Verify that a device on the voice VLAN receives all the correct DHCP options, including the provisioning server address. If possible, boot a single phone on the voice VLAN to verify it retrieves its configuration.

**Ping and jitter test.** From the voice VLAN, run an extended ping test to the VoIP provider's server to baseline latency, jitter, and loss, or run a [VoIP quality test](/tools/voip-test) to get MOS, jitter, and packet loss measurements in a single pass. Run it for at least 15 minutes during business hours. The results should match or improve upon the numbers from your [network assessment](/blog/msp-network-assessment), since QoS is now in place.

## Documentation

Document everything you configure. For every client, maintain a network document that includes:

- VLAN IDs and names (voice VLAN, data VLAN, any others)
- IP subnets for each VLAN with gateway addresses
- DHCP scope ranges and options
- QoS policy details (DSCP markings, queue configurations, bandwidth reservations)
- Firewall rules related to VoIP (ports, protocols, source/destination)
- SIP ALG status (off, and a note about why)
- NAT timeout settings
- Switch port assignments (which ports are configured for voice)

This document saves hours when troubleshooting problems later, when onboarding a new technician to the account, or when the client moves to a new office and you need to replicate the configuration. The time spent documenting now is time saved many times over later.

The network is now ready. In the next post, we move from infrastructure to devices and cover how to get phones configured and deployed without manually touching each one.

*Next up: [Phone Provisioning at Scale](/blog/msp-phone-provisioning), covering auto-provisioning, templates, firmware management, and the logistics of deploying phones by the dozen.*

---

### Part 8: Phone Provisioning at Scale

URL: https://voiptest.com/blog/msp-phone-provisioning
Published: 2026-03-22
Tags: msp, phone-provisioning, auto-provisioning, firmware, deployment

*The MSP's Guide to VoIP: Part 8 of 20*

There is a threshold somewhere around ten phones where manual configuration stops being reasonable and starts being a liability. Configuring three phones by hand is fine. Configuring thirty is tedious. Configuring three hundred one at a time, typing server addresses, extension numbers, and VLAN settings into each phone's web interface, is how mistakes happen and deployments slip by days.

Auto-provisioning is how you scale phone deployments without scaling your labor proportionally. The phone boots, finds its provisioning server, downloads its configuration, and is ready to make calls. No manual configuration per device. No fat-fingered IP addresses. No "I configured 47 phones correctly and the 48th has the wrong codec because I was tired."

## How auto-provisioning works

The basic flow is the same regardless of phone manufacturer or provisioning platform:

1. The phone boots and connects to the network.
2. It receives DHCP options that include the name or URL of a provisioning server ([DHCP option 66](https://www.rfc-editor.org/rfc/rfc2132.html)).
3. The phone contacts the provisioning server and requests its configuration file, typically identified by its MAC address.
4. The provisioning server delivers a configuration file specific to that phone.
5. The phone applies the configuration, registers with the PBX or hosted platform, and is ready.

This entire process takes 30 to 90 seconds depending on the phone model and network conditions. When it works, it is invisible. When it does not, diagnosing the failure point requires understanding each step.

### Provisioning methods

**DHCP-based provisioning (Option 66/67).** The most common method for on-premises deployments. DHCP option 66 carries the name of a TFTP, HTTP, or HTTPS server that hosts configuration files: a string, which is why it usually holds a hostname or a full URL. [Option 150](https://www.rfc-editor.org/rfc/rfc5859.html) is its address-bearing counterpart, carrying one or more IPv4 addresses and taking priority over option 66 when both are set; Cisco phones look for 150 specifically, so a scope that sets only one of the two will provision some vendors and not others. Option 67 can specify a boot file name. When the phone boots and gets its DHCP lease, it reads these options and fetches its configuration. This requires you to run a provisioning server on the network, which might be the PBX itself, a separate server, or a purpose-built provisioning appliance.

**Redirect servers.** Most major phone manufacturers operate cloud-based redirect services. Yealink has RPS (Redirect and Provisioning Service), Grandstream has GDMS (Grandstream Device Management System), Polycom has ZTP (Zero Touch Provisioning). You log into the manufacturer's portal, enter the phone's MAC address, and point it to your provisioning server. When the phone boots, it checks the manufacturer's redirect service first, gets redirected to your server, and downloads its configuration. This works <a href="https://support-cdn.yealink.com/attachment/upload/attachment/2019-5-10/3/46bb4e0f-8dd9-4a50-8a39-c7a783dc42e6/Yealink+SIP+IP+Phones+Auto+Provisioning+Guide.pdf" rel="nofollow noopener noreferrer" target="_blank">even without DHCP option 66</a>, which is useful when you cannot control DHCP (some hosted environments, or networks where DHCP is managed by equipment you do not control).

**Provider-hosted provisioning.** Most hosted VoIP platforms have their own provisioning portals. You add phones by MAC address in the provider's web interface, assign extensions and settings, and the provider's provisioning system handles the rest. The phones are pointed to the provider's provisioning server either through DHCP options or through the manufacturer's redirect service. This is the simplest approach for hosted deployments because the provider manages the provisioning infrastructure.

## Template-based configuration

The power of auto-provisioning comes from templates. Instead of creating a unique configuration file for each phone from scratch, you build templates that handle the common settings and overlay per-phone customizations.

### The base template

The base template contains every setting that should be the same across all phones in the deployment:

- SIP server address and port
- Registration and transport settings (UDP, TCP, TLS)
- Codec priority list (the order in which codecs are offered during call setup)
- VLAN settings (voice VLAN ID, DSCP markings)
- Time zone and NTP server
- Dial plan (patterns for local, long distance, emergency, and internal calls)
- Display language
- Ring tone
- Audio settings (jitter buffer, echo cancellation, VAD)
- Firmware upgrade server address

This template is maintained once and applied to every phone. When you need to change a setting across the entire deployment (adjusting the codec priority, for example, or changing the NTP server), you change the template and the phones pick up the update on their next provisioning cycle.

### Per-phone customization

Layered on top of the base template, each phone gets its own customization that includes:

- Extension number and SIP credentials
- Display name and label
- BLF (Busy Lamp Field) keys configured for the user's most-called internal contacts
- Line key assignments if the phone has multiple lines
- Speed dial entries
- Voicemail access number
- Any user-specific ring or audio preferences

Most provisioning systems let you define these per-phone values in a spreadsheet or CSV that maps MAC addresses to extensions and settings. You export the list from the PBX or provider portal, fill in the per-phone values, and import it into the provisioning system. The system merges the base template with the per-phone values and generates a unique configuration file for each MAC address.

## Firmware management

Firmware updates for IP phones are released regularly and can fix audio processing bugs, security vulnerabilities, compatibility issues, and feature gaps. Keeping firmware current across a deployment is important, but updating firmware carelessly can cause problems.

### Standardize the version

Every phone in a deployment should run the same firmware version. Mixed firmware versions across a deployment create inconsistent behavior. Feature X works on phones running version 1.4 but not on phones running version 1.2. A configuration parameter is interpreted differently between versions. Troubleshooting becomes harder because you cannot reproduce the problem on a phone running a different version.

### Test before rollout

Never push a firmware update to an entire deployment without testing it first. Update two or three phones, use them for several days including making real calls, and verify that registration, audio quality, features, and provisioning all work correctly on the new version. Phone manufacturers occasionally release firmware that introduces new bugs, and the first deployment to discover this should not be your client's entire office.

### Have a rollback plan

Keep the previous firmware version available on the provisioning server so you can roll back if the new version causes problems. Document which version is currently deployed and which version was previously deployed. Some provisioning systems support firmware pinning, where you specify the exact version each phone should run. This prevents phones from automatically upgrading to a version you have not tested.

### Scheduling updates

Schedule firmware updates for outside business hours. The update process typically requires the phone to reboot, which takes one to three minutes during which the phone is unavailable. Phones rebooting in the middle of a business day means missed calls and interrupted conversations. Configure the provisioning system to check for updates during a maintenance window (typically early morning on a weekday, or weekend) and reboot only if an update is available.

## Physical deployment logistics

The technical provisioning is only half the deployment. The physical logistics of getting phones unboxed, labeled, placed on desks, and connected determine whether deployment day goes smoothly or turns into chaos.

### Pre-staging

Before deployment day, prepare every phone:

- Unbox each phone and attach the handset and stand.
- Label each phone with the user's name and extension number. Use a label maker or printed labels on the back or base of the phone. This makes it obvious which phone goes to which desk and makes future support easier when a user calls and says "my phone isn't working" and you need to know which one is theirs.
- If the phones have been pre-registered with the provisioning system by MAC address, verify that each phone's MAC address matches the expected assignment. The MAC address is usually printed on a label on the bottom of the phone.
- If possible, boot each phone on the voice network at your office or staging area to verify that provisioning works. This catches configuration issues before you are on site at the client's office with forty people waiting for their phones.

### Deployment sequence

On deployment day, work in stages rather than connecting all phones simultaneously.

Start with two or three phones at different locations in the office. Verify they boot, receive their configuration, register with the PBX or provider, and can make and receive calls with good audio quality. This confirms that the network preparation from the [previous post](/blog/msp-network-preparation) is working correctly.

Once the first batch is verified, deploy in groups of ten to twenty. This lets you catch issues early (maybe the PoE budget is tighter than expected, or a particular switch port is misconfigured) without having connected every phone first.

### When half provision and half don't

This happens more often than anyone would like. You connect forty phones and thirty boot perfectly. Ten do not. The causes are almost always one of the following:

**DHCP issues.** The voice VLAN DHCP pool is too small, or the DHCP server has run out of addresses, or the lease time is too short and addresses are being recycled while phones are still booting. Check the DHCP server for available leases and errors.

**The wrong DHCP option for that vendor.** The scope sets option 66 but not option 150, or the reverse. Phones that read the option you set provision fine; phones that look for the other one never find the server at all, which is exactly what a half-and-half split across mixed vendors looks like. Set both, pointing at the same server.

**VLAN tagging.** The switch ports for the failing phones are not configured for the voice VLAN. The phone is getting a DHCP lease from the data VLAN instead of the voice VLAN, which means it is getting the wrong DHCP options and cannot find the provisioning server. Check the switch port configuration for the affected ports.

**Firewall blocking provisioning.** The provisioning server is reachable from the voice VLAN in general, but a specific firewall rule is blocking traffic from the subset of phones that are failing. Or, the phones are reaching a different firewall rule path due to an IP range issue.

**DNS resolution.** The phone is trying to resolve the provisioning server hostname and DNS is not responding or returning the wrong address. This is especially common when the provisioning server is specified by hostname rather than IP address in the DHCP options, which is the whole reason option 150 exists alongside option 66. If phones are failing to register after provisioning, check the [SIP Response Codes](/tools/sip-codes) reference to interpret the specific error the phone is returning.

**MAC address mismatch.** The MAC address entered in the provisioning system does not match the actual MAC address of the phone. One transposed character in a MAC address means the provisioning server has no configuration for that phone. Verify the MAC addresses against the labels on the phones.

Approach the diagnosis systematically: check DHCP first (is the phone getting the right IP and options), then VLAN (is the phone on the right network), then DNS (can the phone resolve the provisioning server), then connectivity (can the phone reach the provisioning server), then authentication (does the provisioning server recognize the phone's MAC address). This sequence eliminates the most common causes first.

## Ongoing provisioning

Provisioning is not a one-time event. After the initial deployment, the provisioning system continues to serve configuration updates to phones as you make changes: adding new extensions, updating BLF keys when someone's role changes, adjusting codec settings, pushing firmware updates, or modifying dial plans.

Maintain the provisioning system as part of your ongoing management of the client's voice environment. Keep templates current, keep the per-phone data accurate, and keep the provisioning server accessible and maintained. A well-maintained provisioning system means that adding a new phone to the deployment takes minutes, not hours, and that configuration changes propagate automatically rather than requiring manual updates to individual phones.

*Next up: [Trunk Configuration and Inbound Routing](/blog/msp-trunk-configuration), covering SIP trunks, DID routing, caller ID, and the E911 setup that cannot be skipped.*

---

### Part 9: Trunk Configuration and Inbound Routing

URL: https://voiptest.com/blog/msp-trunk-configuration
Published: 2026-03-23
Tags: msp, sip-trunk, inbound-routing, did, e911, voip-deployment

*The MSP's Guide to VoIP: Part 9 of 20*

> **Disclaimer:** This post is educational content about SIP trunk configuration and deployment practices. It is not legal advice. Regulations change, interpretations vary, and your specific situation may differ from the general scenarios described here. Consult with a telecom attorney to determine how these regulations apply to your business.

You've got the network sorted, the phones are provisioned, and the PBX is configured. Now comes the piece that connects everything to the outside world: the SIP trunk. This is where your client's phone system meets the public telephone network, and getting it right determines whether calls actually work once you flip the switch.

Trunk configuration isn't conceptually difficult, but it has enough moving parts that skipping a step or making an assumption about a default setting can leave you troubleshooting one-way audio or failed outbound calls on go-live day. Let's walk through the whole process from trunk provisioning to inbound routing to the E911 setup that absolutely must happen before anyone makes a call.

## Choosing a trunk provider

If you're deploying a hosted PBX platform, the trunk is usually bundled. The platform provider handles the SIP connectivity to the PSTN, and you configure routing within their portal. You still need to understand how it works, but you're not selecting a separate trunk provider.

For on-premises PBX deployments (FreePBX, 3CX, Asterisk, or similar), you're choosing a SIP trunk provider separately. The major considerations are geographic coverage, pricing structure (per-minute vs. unlimited channels), number porting support, and how well they work with your specific PBX platform. Some trunk providers have known compatibility issues with certain PBX platforms, and discovering that after you've ported numbers is not a situation you want to be in.

Ask other MSPs what they use. Check the PBX vendor's documentation for tested trunk providers. If the provider offers a trial with temporary DIDs, set one up and test it with your PBX before committing. An hour of testing now saves a day of troubleshooting later.

## IP authentication vs. registration authentication

SIP trunks authenticate in one of two ways, and which one you use depends on the deployment scenario.

**IP authentication** ties the trunk to a specific public IP address. The trunk provider's system says "if SIP traffic comes from 203.0.113.50, it's authorized for this account." No username or password is exchanged in the SIP messages. This is the standard approach for on-premises PBX deployments where the PBX sits behind a static public IP. It's simpler (no credentials to manage), slightly more efficient (no registration overhead), and generally more reliable since there's no registration that can expire or fail.

The catch is that you need a static public IP, and if the IP changes (ISP change, office move), you need to update the trunk provider's configuration before calls will work again. If you've read the [SIP registration post](/blog/sip-registration), you know how registration-based auth works in detail.

**Registration authentication** uses a username and password. The PBX registers with the trunk provider periodically (typically every 60-120 seconds), and the provider authenticates each registration and call attempt using SIP digest authentication. This is the right choice when the PBX doesn't have a static IP (rare for business, but it happens), when the PBX is behind a NAT that changes the source port unpredictably, or when the deployment is in a cloud environment with elastic IP addressing.

Registration auth adds a small amount of overhead and introduces the possibility of registration failures, but it works regardless of the source IP. If your client's ISP provides a dynamic IP and won't sell them a static one, registration auth is your only option.

For most on-premises MSP deployments with a business-grade internet connection that includes a static IP: use IP authentication. It's one less thing that can break.

## Codec selection on the trunk

Here's where a lot of MSPs leave performance on the table. The codec used on the SIP trunk should match what the phones are using internally. If your phones are using G.711 internally and the trunk is configured for G.729, every call that crosses the trunk gets transcoded. Transcoding adds latency, uses CPU on whatever device is doing the transcoding (usually the PBX), and can introduce subtle audio quality degradation. The [SDP media negotiation post](/blog/sdp-media-negotiation) covers how codec selection works at the protocol level.

**G.711 (a-law or u-law)** is the standard choice for quality. It uses about 87 kbps per call with overhead, sounds excellent, and requires zero transcoding when talking to the PSTN (which natively uses G.711). If the internet connection has sufficient bandwidth for the expected number of concurrent calls, use G.711 everywhere: on the phones, on the PBX internally, and on the trunk. Consistency eliminates transcoding entirely.

**G.729** compresses voice to 8 kbps at the codec level, which works out to approximately 24 to 32 kbps per call with IP, UDP, RTP, and Layer 2 overhead. The audio quality is noticeably lower than G.711 (though still acceptable for business calls), but if bandwidth is constrained, it lets you fit more concurrent calls on the connection. Some trunk providers charge extra for G.729, and some don't support it at all.

**Opus** is the modern codec that offers excellent quality at variable bitrates. Support on SIP trunks is still spotty as of this writing, but it's becoming more common. If your PBX and trunk provider both support Opus, it's worth testing. The quality at equivalent bitrates is superior to both G.711 and G.729.

The rule is simple: match the trunk codec to the internal codec. If phones use G.711, configure the trunk for G.711. If you must use a different codec on the trunk than internally, make sure the PBX has the CPU headroom to handle the transcoding load for all concurrent calls, not just the two test calls you tried during setup.

## Configuring the trunk on the PBX

The specific steps vary by PBX platform, but the information you need from the trunk provider is the same:

The SIP server address (or addresses, if they provide primary and failover). The port (usually 5060 for UDP/TCP, 5061 for TLS). The authentication credentials (if using registration auth). The allowed codecs and their priority order. Any specific SIP headers the provider requires (some need a specific domain in the From header, some need a P-Asserted-Identity header for caller ID).

Enter this information in the PBX's trunk configuration. For IP auth, you'll also need to give the trunk provider your public IP address (and update it if it ever changes). For registration auth, watch the PBX's registration status after saving the configuration. It should show as registered within a few seconds. If it doesn't, check the credentials, check that the PBX can reach the provider's SIP server (firewall rules, DNS resolution), and check for [NAT traversal issues](/blog/sip-nat-traversal).

Once the trunk is connected, make a test outbound call to a mobile phone. If it connects and you have two-way audio, the trunk is fundamentally working. If you get one-way audio (you can hear them but they can't hear you, or vice versa), you have a NAT or media routing issue that needs to be resolved before going further. If the call fails outright, check the [SIP Response Codes](/tools/sip-codes) reference to interpret the error, and use [SIP Call Stories](/tools/sip-call-stories) to walk through what a healthy call exchange should look like compared to what you are seeing.

## Inbound routing: DIDs to destinations

With the trunk connected, inbound calls need to go somewhere. This is where DIDs (Direct Inward Dialing numbers) get mapped to internal destinations. The concept is straightforward: when a call comes in on a specific DID, send it to the configured destination. The destination can be an extension, a ring group, an auto attendant, a call queue, or a voicemail box.

**Direct extension mapping.** The simplest case: DID 555-0100 rings extension 100. DID 555-0101 rings extension 101. One DID per person, one destination per DID. This is common for executives or key staff who need direct lines.

**Main number to auto attendant.** The company's main number routes to an auto attendant (also called an IVR) that plays a greeting and offers options. "Press 1 for sales, 2 for support, 3 for billing." Each option routes to a ring group, queue, or specific extension. Design the auto attendant menu with the client. Keep it to three or four options at most. Nobody wants to listen to nine options, and the people who call most frequently already know which number to press.

**Ring groups.** A set of extensions that ring together when a call hits the group. Useful for departments: the sales ring group rings all five sales people simultaneously (or sequentially, or in a hunt pattern). Configure the ring strategy (simultaneous, sequential, round-robin), the ring time before moving to the next step, and the failover destination (usually voicemail for the group, or the receptionist, or back to the auto attendant).

**Call queues.** For teams that handle high call volumes and need calls held in order until an agent is available. Queues play hold music or periodic announcements while the caller waits. Configure the queue strategy, the hold music, the maximum wait time, and what happens when the queue is full or the wait time is exceeded.

Get the routing plan from the client in writing before configuring anything. Draw it as a flow chart if that helps. "When someone calls the main number, what happens? If nobody answers sales after 30 seconds, where does the call go? What happens after hours?" Walk through every path a call can take, including the edge cases. What happens at lunch? What happens on holidays? What happens if all lines are busy?

## Outbound routing and caller ID

Outbound calls need rules too. The PBX needs to know which trunk to use for outbound calls (if there's more than one), and the calling number presentation needs to be correct.

**Caller ID configuration.** When your client's staff make outbound calls, the caller ID displayed to the recipient should show the company's number, not some random number from the trunk provider's pool. Configure the outbound caller ID on the trunk to use the appropriate DID. Some companies want all outbound calls to show the main number. Some want each user's direct DID to show when they call out. Some want department-specific numbers. Ask the client, configure it, and test it by calling a mobile phone and checking what shows up.

CNAM (Caller Name) is the name that displays alongside the caller ID number. CNAM registration is a separate process from number assignment. Your trunk provider should be able to register the CNAM for your DIDs, but it can take days to propagate through the various databases that carriers query. Start this process early. A call from "WIRELESS CALLER" or "UNKNOWN" looks unprofessional. The [caller ID problems post](/blog/caller-id-problems) covers the full picture of what can go wrong here.

**Dialing rules.** Configure how the PBX handles different types of outbound calls. Local calls (7 or 10 digits depending on the region), long distance (1 + 10 digits), international (011 + country code + number), and emergency calls (911). Some PBX platforms handle this automatically based on the trunk provider's expectations. Others need explicit outbound route patterns.

If the client needs to restrict certain call types (block international dialing for most extensions, for example), configure those restrictions in the outbound routes. It's easier to set this up during deployment than to explain a surprise $800 international call charge a month later.

**Emergency calling rules deserve their own configuration check.** The PBX must be configured so that 911 calls are never blocked by any restriction, class of service, or routing rule. Test this explicitly. Every extension should be able to dial 911 regardless of any other outbound restrictions. (Test with your trunk provider's designated test number, not actual 911.)

## Testing every path

Before moving on to E911 configuration, test every inbound and outbound path systematically. This isn't "make a couple of calls and call it done." This is a checklist:

Outbound call from a desk phone to a mobile number. Verify two-way audio, verify caller ID shows correctly. Outbound call from a softphone (if applicable). Same checks. Inbound call to the main number. Verify the auto attendant answers, every menu option routes correctly, and the timeout behavior works as expected. Inbound call to each DID that's mapped directly to an extension. Verify the correct phone rings.

Ring group test: call a ring group, verify the configured ring pattern (do all phones ring simultaneously? do they ring in sequence?). Let it ring past the timeout and verify the failover works. Queue test if applicable: call into the queue, verify hold music plays, verify the call routes to an available agent. After-hours test: change the time condition to after-hours mode and call in, verify the after-hours greeting and routing.

Voicemail: call an extension, let it go to voicemail, leave a message, verify the message shows up in the right mailbox. If voicemail-to-email is configured, verify the email arrives.

Document each test and its result. If something doesn't work, fix it now. Every path you don't test is a path that might fail on go-live day in front of the client and their staff.

## E911 configuration: this is not optional

E911 (Enhanced 911) is the part of VoIP deployment that has life-or-death consequences if you get it wrong. When someone at your client's office dials 911, the call needs to reach the correct PSAP (Public Safety Answering Point), and the correct physical address needs to be transmitted to the dispatcher. With [traditional phone lines](/blog/voip-lines-dont-exist), the address was tied to the physical line. With VoIP, the address is configured in software, which means it can be wrong.

Every VoIP deployment must have E911 configured with the correct physical address before anyone makes a call from the system. This is not a "we'll get to it after go-live" item. This is a "we don't go live until this is confirmed working" item.

**Address registration.** Your trunk provider or hosted PBX platform has an E911 configuration section. Enter the physical street address of the client's office. This address must be the actual location where the phones are, not the client's billing address, not their PO Box, not their headquarters if the phones are at a branch office. The address must be validated (the provider will check it against the MSAG database, which is the master street address guide used by 911 systems). If the address doesn't validate, you may need to adjust the format (Street vs. St., Suite vs. Ste.) until it matches what the MSAG expects.

**Per-location configuration.** If the client has multiple locations, each location needs its own E911 address. If the PBX serves all locations, each location's trunk or DID range needs to be associated with the correct address. A call from the downtown office must send the downtown address, not the warehouse address.

**Remote workers.** If employees use softphones or desk phones at home, their E911 address should be their home address, not the office address. Some platforms support dynamic E911 where the address is associated with the user's current location. If the platform doesn't support this, remote workers need to be aware that 911 calls from their VoIP phone may not send the correct address, and they should use their mobile phone for 911 calls.

**Testing E911.** Most trunk providers have a way to test E911 routing without actually calling 911. Some provide a test number. Some have a validation tool in their portal that confirms the address is registered and routes correctly. Use whatever testing method is available. If none is available, call the trunk provider's support and ask them to verify the E911 configuration for each address.

Do not skip E911 configuration. Do not defer it. Do not assume it was set up automatically. Verify it yourself, document it, and include it in the go-live checklist. If an employee has a medical emergency and dials 911, and the call doesn't connect or connects with the wrong address, that's on whoever deployed the system.

## Regulatory position check

If you are configuring your own SIP trunks for client voice service, you may now be operating as a voice service provider under FCC rules. This is true whether you think of yourself as an MSP, a reseller, or an IT consultant. The FCC classifies providers based on what they do, not what they call themselves.

Before going live with client traffic on your own trunks, verify your regulatory position. Do you need FCC registration? An Operating Company Number (OCN)? STIR/SHAKEN compliance? A filing in the Robocall Mitigation Database? The answers depend on the specifics of your arrangement with the trunk provider and how your service is structured, but the questions are not optional.

See Parts 17 through 20 of this series for the full picture of voice service provider obligations, and consult a telecom attorney before going live with client traffic on trunks you contract for directly.

## Multi-site trunk considerations

If the client has multiple locations sharing a centralized PBX (common with cloud-hosted platforms), each location's calls should egress with the correct local caller ID and route to the correct local PSAP for 911. This usually means having DIDs from each location's local rate center and configuring the system so outbound calls from each location use that location's DIDs.

Some trunk providers offer location-aware trunking where you can tag traffic from different locations and have different caller ID and E911 settings per location on the same trunk account. Others require separate trunk configurations per location. Either approach works; just make sure every location has the right outbound caller ID and the right E911 address.

## SIP trunk security

SIP trunks are a target for toll fraud. If someone gains access to your trunk credentials or can send SIP traffic from an authorized IP, they can make international calls on your client's account. A weekend of fraudulent calls to premium-rate numbers can generate thousands of dollars in charges.

**IP authentication** provides inherent protection since only traffic from the authorized IP is accepted. But if the PBX itself is compromised, the attacker can make calls through the trunk.

**Registration authentication** requires the credentials to be protected. Don't use weak passwords. Don't reuse credentials across clients. Don't store credentials in plain text in documentation that's shared widely.

**Rate limiting on the trunk provider side.** Most providers offer fraud protection features: concurrent call limits, per-minute spending caps, international call blocking, and alerts for unusual call patterns. Enable all of them. Set the concurrent call limit to slightly above the client's expected maximum (if they normally have 10 concurrent calls, set the limit to 15, not unlimited). Block international destinations the client doesn't call. Set a daily spending cap that would catch a fraud attempt before it gets expensive.

**PBX-side protections.** Use strong passwords for all SIP extensions. Disable unused extensions. Use a firewall or SBC (Session Border Controller) in front of the PBX to limit SIP access to known sources. Monitor call detail records for unusual patterns (calls at 3 AM, calls to premium-rate numbers, sudden spikes in concurrent calls).

## The trunk configuration checklist

Before moving to go-live, verify each of these:

Trunk is connected and authenticated (registration status shows active, or IP auth is confirmed). Codec on the trunk matches internal codec (no unnecessary transcoding). Every DID routes to the correct internal destination. Auto attendant menus work correctly with proper timeouts and failovers. Ring groups ring in the configured pattern with correct failover. After-hours routing works correctly. Outbound caller ID shows the correct number for each extension or department. CNAM is registered and propagating. International dialing restrictions are in place if needed. E911 address is registered, validated, and correct for each location. Emergency calls route correctly from every extension. Fraud protection settings are enabled on the trunk provider's account. Concurrent call limit is set appropriately. The client has the trunk provider's support contact information.

That's a lot of items. It's a lot of items because getting the trunk right is what makes the whole deployment work. The prettiest phone system in the world is useless if calls don't connect, caller ID is wrong, or 911 doesn't work. Take the time, test every path, verify every setting.

*Next up: [Go-Live Day and the First Week](/blog/msp-go-live-day)*

---

### Part 10: Go-Live Day and the First Week

URL: https://voiptest.com/blog/msp-go-live-day
Published: 2026-03-23
Tags: msp, go-live, cutover, number-porting, deployment, training

*The MSP's Guide to VoIP: Part 10 of 20*

Everything has been configured, tested, and documented. The trunk is connected, the routing is in place, the phones are provisioned. Now comes the part that separates a smooth deployment from one that becomes a story your technicians tell at happy hour for years: go-live day. And the first week after it, which is where the real test happens.

Go-live day is a project management exercise as much as a technical one. The technical work is mostly done. What matters now is sequencing, communication, timing, and having a plan for when things don't go exactly as expected. Because they won't. They never do.

## Picking the right day and time

Friday afternoon is not the right time to cut over a phone system. Monday morning is not ideal either. The best go-live window is Tuesday or Wednesday morning, early. This gives you the full day to work through issues, a day or two of normal business operation to shake things out, and the weekend as a buffer before the next full business week.

If the client insists on a Monday go-live, push for early morning, before the office opens. If they insist on Friday, make sure you and your team are available through the weekend for emergency support. It happens. Just price it accordingly.

Avoid month-end, quarter-end, or any period when the client's call volume is unusually high. Don't go live the week of the client's biggest annual event. Ask the client when their busiest call periods are and avoid those windows. The worst time to discover a routing issue is when the sales team is handling peak inbound volume.

## Number porting coordination

If you're porting numbers from an existing carrier to the new trunk provider, the port date is your go-live date. Number porting is covered in detail in the [porting numbers post](/blog/porting-numbers-office-move), but the key points for go-live planning are:

Ports are scheduled in advance but the exact completion time is unpredictable. The old carrier releases the numbers on the scheduled date, but it might happen at 8 AM or it might happen at 2 PM. Your trunk provider will notify you (or you can watch their portal) when the port completes. Until the port completes, inbound calls still go to the old system.

This means you need an overlap period. The old phone system should remain operational until the port is confirmed complete. Don't decommission the old system the night before the port date. Leave it running. Once the port completes, test inbound calls to every ported number on the new system. Only after confirming that all numbers are working on the new system should you consider shutting down the old one.

Keep the old system available (not necessarily active, but available) for at least a week after the port. If something goes wrong and a number needs to be ported back, having the old system intact makes that process much less painful. Think of it as a rollback option.

## The rollback plan

Speaking of rollback: have one. Before go-live, document exactly what you would do if the new system has a critical failure that can't be resolved within a reasonable time frame. "Reasonable" depends on the client. For a medical office, an hour of no inbound calls is a crisis. For a consulting firm, half a day is uncomfortable but survivable.

The rollback plan typically involves forwarding numbers from the new system back to the old system (if the old system is still active), or forwarding to mobile phones as an emergency measure. The specifics depend on the deployment, but the important thing is that the plan exists, is documented, and everyone involved knows what triggers it.

Define the trigger criteria with the client before go-live. "If inbound calls are not working within two hours of the scheduled port completion, we will forward the main number to [mobile number] while we troubleshoot." Having this agreed upon in advance avoids a panicked negotiation in the middle of a problem.

## Go-live day: the testing sequence

When go-live morning arrives, you need a systematic testing sequence. Don't just turn everything on and hope for the best. Test in layers, from infrastructure up to user-facing functionality.

### Layer 1: Internet connectivity

Verify the internet connection is up and performing normally. Run a speed test and a [VoIP quality test](/tools/voip-test) to confirm that latency, jitter, and packet loss are within acceptable ranges. Check latency to the trunk provider's SIP server (a simple ping, though ICMP isn't always the best proxy for SIP performance). If the connection is degraded on go-live morning, you want to know before you start routing calls over it, not after.

If there's a backup internet connection, verify it's also operational. If QoS is configured on the router, verify the rules are active (not just configured but actually applied to the correct interface and functioning).

### Layer 2: Network core

Verify the switches are up, VLANs are configured correctly, and the phones can reach the PBX (or hosted platform). Pick up a desk phone and check that it's registered and showing the correct extension. If the phones booted overnight and auto-provisioned, they should be ready. If any phones show errors or aren't registered, troubleshoot those individually before proceeding.

Check the PBX's trunk status. Is the SIP trunk registered (or, for IP auth, is it showing as connected)? If the trunk isn't up, nothing else matters. Fix the trunk first.

### Layer 3: Phone deployment in stages

Don't test all 50 phones at once. Start with a small group, ideally the IT contact's phone and two or three others in different parts of the office. Make test calls: outbound to a mobile, inbound from a mobile. Verify two-way audio, call quality, caller ID display, and voicemail. If this small group works, expand to the next group. If it doesn't, you've isolated the problem to a manageable scope.

For larger deployments (more than 20 phones), consider going live in phases: one department or one floor at a time. If the sales team goes live first and there's an issue, the rest of the company is still on the old system. This reduces blast radius and lets you fix problems while only a subset of users is affected.

### Layer 4: Critical workflows

Once basic calling works, test the specific workflows the client cares about most:

**The main number.** Call the main number from an external phone. Does the auto attendant answer? Do all the menu options work? Does the timeout route correctly? If a receptionist handles calls, does the call land on their phone as expected?

**Ring groups.** Call each ring group. Verify the ring pattern (simultaneous, sequential, whatever was configured). Let it ring past the timeout. Does it fail over correctly?

**Call queues.** If the client uses queues, put a test call into the queue. Verify hold music plays, the call routes to an available agent, and the queue statistics display correctly in whatever interface the supervisors use.

**Voicemail.** Leave a message. Check that the message notification works (visual voicemail indicator on the phone, email notification if voicemail-to-email is configured). Have the user retrieve the message and confirm it plays correctly.

**Transfer.** Have someone answer a call and transfer it (blind transfer and attended transfer). This is the operation that trips up the most users, and if the transfer function doesn't work correctly, you'll hear about it within the first hour.

**Conference calling.** If the system supports ad-hoc conferencing, test it. Initiate a three-way call and verify everyone can hear each other.

### Layer 5: Remote access

If any users are working remotely with softphones or remote desk phones, verify their connectivity. Have them make and receive test calls. Remote users are often the last to be tested and the first to have problems because their network conditions are less controlled.

## Training on go-live day

Even if you provided training before go-live, plan for a brief refresher on go-live morning. With the actual working system in front of them, users will pay more attention and ask better questions than they did during pre-deployment training with theoretical scenarios.

Keep go-live day training short and focused on daily operations: answering calls, transferring calls, accessing voicemail, and putting calls on hold. This is not the day for advanced features. People are already dealing with the stress of change. Give them the basics, make sure they're comfortable, and save the advanced training for week two.

Print a one-page quick reference card with the most common operations. Place one at every desk. Yes, it's on the phone's screen too. Yes, it's in the documentation you emailed. Put a physical card at the desk anyway. When someone is on a call with a client and can't figure out how to transfer, they're not going to search their email for documentation. They're going to look at the card on their desk.

## The first week: brace for it

Go-live day went well. Everything tested fine. Users made it through the day. You drive home feeling good about the deployment. And then the calls start coming in on day two.

The first week after a VoIP deployment is when users discover all the things they forgot to mention during the planning phase, all the workflows they didn't think to describe, and all the habits from the old system that don't translate to the new one. This is normal. It's not a failure of your planning. It's just what happens when a group of people starts using a new system under real conditions.

### The hold button crisis

Someone will not be able to find the hold button. Or they'll press hold and not know how to retrieve the call. Or they'll press transfer when they meant to press hold, and lose the call. This happens on every deployment with every phone system. The phone's interface is different from what they're used to, and muscle memory from the old system doesn't help with the new one.

Be patient. Walk them through it. Update the quick reference card if the hold/transfer process isn't clear. This is a training issue, not a system issue, but it feels like a system issue to the user who just accidentally hung up on a client.

### Voicemail PIN chaos

Half the users didn't set up their voicemail PIN during training, or they set it up and immediately forgot it. Now they have messages they can't access. Have a process for resetting voicemail PINs quickly. On most platforms, the admin can reset a PIN in the management portal in about thirty seconds. Make this easy for whoever is handling first-week support.

### Ring groups don't match reality

During planning, the client said the support team has four people and they all answer calls equally. In reality, two of them are part-time and only available in the mornings, one is in a different office, and the fourth handles overflow from the sales team before answering support calls. The ring group you configured doesn't match how the team actually works.

This is the most common post-go-live adjustment. Ring group membership, ring patterns, and failover behaviors almost always need tweaking once the team starts using the system in their actual workflow. Budget time for ring group adjustments in the first week. Make changes during low-volume periods and test each change after making it.

### The conference room phone nobody tested

Every deployment has a phone or a room or a device that somehow got skipped during testing. The conference room speakerphone that was in a box on go-live day. The phone at the reception desk that was unplugged because the receptionist was on vacation. The fax machine that connects through an ATA that nobody configured.

Walk the office on day two or three and check every phone, every conference room, every shared device. Don't assume that if nobody reported a problem, everything is working. Some people will just quietly work around a broken phone for days before mentioning it.

### Remote worker issues surface gradually

Remote workers who tested fine on go-live day might have intermittent issues that only appear under certain conditions. Their home WiFi gets congested when the kids come home from school. Their ISP has packet loss during peak hours. The VPN connection drops their softphone registration periodically. These issues take time to surface because they're intermittent and depend on conditions at the remote worker's location.

Have remote workers report any call quality issues during the first week, even intermittent ones. If a pattern emerges, troubleshoot the remote worker's network environment. The [office move telecom checklist](/blog/office-move-telecom-checklist) has relevant guidance on testing network conditions that applies to remote setups too.

## Being responsive without setting a precedent

Here's the management challenge of the first week: you need to be highly responsive to build confidence in the new system and your support, but you also need to avoid establishing an expectation that every phone question gets an immediate, personal response from the MSP forever.

During the first week, respond quickly to every issue. Fix what's broken, answer questions, adjust configurations. This is what builds the client's confidence that the deployment was done well and that you'll take care of them.

But also start channeling requests through the proper support process. If the client's users are texting your personal phone with questions, gently redirect them to the ticketing system or the designated support contact at the client's office. "Happy to help with this. For the fastest response going forward, email support@ or call the help desk."

Designate a point person at the client's office: someone who can handle the basic questions (how do I transfer a call, what's my voicemail PIN) without calling you. Train this person thoroughly. Give them admin access to the phone system portal if appropriate, so they can reset voicemail PINs and check extension status without opening a ticket. This person is your first line of defense against a flood of minor requests that don't need MSP-level attention.

## Collecting feedback systematically

Don't rely on people coming to you with problems. Proactively collect feedback during the first week. A simple email to all users on day three asking "How is the new phone system working for you? Any issues or questions?" will surface problems that users assumed were just how the new system works and weren't worth reporting.

A brief survey at the end of the first week (five questions maximum, keep it short) gives you structured feedback. Ask about call quality, ease of use, any features they're missing from the old system, and anything that's frustrating about the new system. The answers will tell you what needs adjustment and what needs additional training.

## The one-week check-in

Schedule a formal check-in meeting with the client's decision maker at the end of the first week. Review the issues that came up, the changes that were made, and the outstanding items. This is your opportunity to demonstrate that the deployment is on track and that you're managing the transition professionally.

Bring a list of every issue reported and its resolution status. Include the changes you made proactively (ring group adjustments, voicemail PIN resets, etc.) and any items that are still pending. This kind of structured follow-up builds trust and shows the client they made the right choice.

Use this meeting to also set expectations for the next few weeks. "We expect a few more adjustments as everyone settles in. Here's how to report issues. We'll do another formal check-in at the one-month mark."

## The one-month check-in

By one month in, the system should be stable and users should be comfortable with daily operations. The one-month check-in is about confirming that everything is working well and transitioning from deployment mode to ongoing support mode.

Review call quality data if the system provides analytics. Check for patterns: are there times of day when call quality dips? Are certain extensions having more issues than others? If monitoring is in place, review the monitoring data and address any trends before they become problems.

Discuss any features or changes the client wants now that they've had a month of experience with the system. The things they thought they needed during planning may not be the things they actually need now that they're using it. Advanced features they dismissed during deployment ("we don't need call recording") might be things they're now interested in.

Close out the deployment project formally. Deliver the final documentation package: network diagrams, extension list, trunk configuration details, admin credentials, support contact information. Define what constitutes ongoing support versus deployment-related work. Move from project mode to support mode.

## The deployment isn't done when the phones work

A successful VoIP deployment isn't measured on go-live day. It's measured at the one-month mark when the client says "the phones are working great and the team is happy." Getting to that point requires more than good technical work. It requires managing the transition, being available during the critical first week, collecting and acting on feedback, and following through with structured check-ins.

The clients who become long-term, high-value MSP relationships are the ones where the deployment went smoothly and the follow-up was thorough. The actual technical configuration is maybe 60% of what makes a deployment successful. The other 40% is communication, project management, and being there when things don't work as expected. Which they won't. They never do. But that's what you're there for.

Before proceeding further in your voice deployment, make sure you understand the regulatory obligations that come with offering voice services. Parts 17 through 20 of this series cover FCC registration, STIR/SHAKEN, and the Robocall Mitigation Database. These are not optional and the consequences of non-compliance are severe.

*Next up: [Monitoring VoIP Quality Proactively](/blog/msp-proactive-monitoring)*

---

### Part 11: Monitoring VoIP Quality Proactively

URL: https://voiptest.com/blog/msp-proactive-monitoring
Published: 2026-03-24
Tags: msp, voip-monitoring, call-quality, mos-score, proactive-management

*The MSP's Guide to VoIP: Part 11 of 20*

There is a moment in every MSP's voice business that separates the operators from the order-takers. It is not the deployment. It is not the first trouble ticket. It is the first time a client calls to say "the phones have been sounding bad for a couple of weeks" and you had no idea.

That moment stings, because the whole value proposition of managed services is that someone is watching. If you are managing a client's endpoints, you know when antivirus definitions are out of date before anyone gets infected. If you are managing their backups, you know when a job fails before anyone needs a restore. But if you are managing their phones and you find out about a quality problem from the client, you are not managing. You are just billing.

Proactive voice monitoring is what closes that gap. It is also, honestly, one of the areas where most MSPs under-invest. The tools exist. The data is available. The problem is usually that nobody has set up the workflows to turn raw metrics into actionable awareness.

This post is about building that workflow. The principles apply regardless of what platform you are running, and the goal is a framework for knowing about problems before the client does.

## What you are actually monitoring

Voice quality monitoring has four distinct layers. Each one answers a different question, and you need all four for a complete picture.

### CDR analysis: did calls succeed?

Call Detail Records are the most basic monitoring layer, and the one most MSPs already have some access to. Every PBX and hosted platform generates CDRs, and they contain a surprising amount of signal if you know what to look for.

The obvious metric is completion rate. What percentage of outbound calls resulted in a connection? A healthy system typically shows a completion rate above 95% for outbound calls (accounting for the natural rate of no-answers, busy signals, and invalid numbers), though the number is heavily dependent on the destinations and routes a client actually calls: establish their own baseline and alert on movement away from it rather than treating 95% as a universal figure. If completion rates drop below that baseline, something is wrong, whether with your trunking, your signaling, or the destination network.

But completion rate alone misses a lot. Duration anomalies are equally telling. If your average call duration across a client's system suddenly drops from four minutes to two minutes, people might be hanging up because the audio is bad, even though the calls technically "completed." Build a baseline of average duration by extension, by trunk group, by time of day, and watch for deviations.

Short calls are a particularly useful signal. A spike in calls under 30 seconds, especially outbound calls, often indicates a quality problem that is causing people to hang up and redial, or an [audio issue](/blog/choppy-robotic-audio) that makes the first few seconds of a call unusable. These are calls that connected successfully from a signaling perspective but failed from a user experience perspective. CDRs alone will not tell you the call sounded bad, but the pattern of short duration followed by immediate redial is a strong indicator.

Also track call volume trends. A client that normally averages 200 calls per day and suddenly drops to 150 might be routing calls through cell phones because the desk phones are unreliable. They may not have called you yet. People adapt to problems faster than they report them.

### RTP quality metrics: how did calls sound?

This is where the real quality data lives. RTP (Real-time Transport Protocol) carries the actual audio, and most PBX platforms and many hosted providers [expose RTP quality metrics](https://www.rfc-editor.org/rfc/rfc6035.html) either per-call or in aggregate.

The metrics that matter are the same ones covered in the fundamentals series: [MOS score](/blog/understanding-mos-scores), [jitter](/blog/what-is-jitter-and-why-it-matters), and [packet loss](/blog/understanding-voip-packet-loss). If your platform reports these per-call, you have everything you need to trend quality over time.

**MOS** is the summary metric. As covered in the [MOS post](/blog/understanding-mos-scores), the working convention is that a score above 4.0 is excellent, 3.6 to 4.0 is good, and anything below 3.6 will generate complaints. These are operating bands rather than a published scale, and worth stating as such to a client. One thing to be clear about in a report: what a PBX or probe hands you is almost always [an estimate computed from an E-model R factor](https://www.rfc-editor.org/rfc/rfc3611.html), not a score real listeners gave, and that estimate tops out at 4.5 rather than 5. The [MOS Explorer](/tools/mos-explorer) lets you experiment with how loss, jitter, and codec choice move the score. Set your sustained-monitoring alert at 3.9, matching the warning trigger below, which gives you a buffer before quality reaches the point where users notice.

**[Jitter](https://www.rfc-editor.org/rfc/rfc3550.html)** should be consistently under 20 milliseconds. Occasional spikes above that are normal. Sustained jitter above 40 milliseconds will start affecting audio quality even with a good jitter buffer, which is why that is the critical trigger below. If you see jitter climbing over a period of days or weeks, something in the network path is degrading.

**Packet loss** above 1% is cause for investigation. Above 2% is cause for action. Even 1% random loss drops MOS noticeably, and bursty loss (multiple consecutive packets) is worse than random loss at the same percentage because the jitter buffer cannot conceal the gaps.

The challenge is that not every platform makes these metrics equally accessible. Some PBX systems (FreePBX, 3CX, and similar) log RTP quality in CDRs or in separate quality reports. Many hosted platforms provide quality dashboards in their admin portals. Some expose the data through APIs, which is ideal for pulling into your own monitoring stack. If your platform does not expose RTP quality metrics at all, that is a significant gap and worth raising with the vendor.

One practical note: RTP quality metrics from the PBX or platform typically reflect what the system observed at its end of the call. They do not necessarily reflect what the user heard at the handset. If the quality degradation is happening between the PBX and the endpoint (for example, on the client's [local network](/blog/wired-vs-wifi-for-voip)), the PBX-side metrics might look fine while the user experience is poor. This is why network monitoring matters as a complementary layer.

### Network monitoring: is the path healthy?

Voice quality depends on network conditions, and network conditions change over time. The network that was perfectly healthy when you [deployed the system](/blog/msp-go-live-day) may not be perfectly healthy six months later. New employees bring new devices. New applications consume bandwidth. ISP performance shifts with changing traffic patterns.

Monitor the metrics that directly affect voice at the network level:

**Bandwidth utilization.** Track upload and download utilization on the client's internet connection over time, especially during business hours. Trending toward saturation is a leading indicator of future quality problems. If a 50 Mbps upload link is routinely hitting 40 Mbps during the afternoon, you are one cloud backup job or one large file transfer away from [congestion that degrades every call](/blog/afternoon-call-quality).

**Latency to key destinations.** Run continuous ping or synthetic probes from the client's network to their VoIP provider's signaling and media servers. Baseline the latency, and alert on deviations. A sudden increase in latency to the provider, even if it is still within acceptable bounds, can indicate a routing change or congestion in the [internet path](/blog/diagnosing-voip-problems) that may worsen.

**Jitter and loss on the WAN link.** If you have SNMP access to the client's router, you can pull interface error counters, discard counters, and utilization data. Rising discard counts on the WAN interface are a direct indicator that the router is dropping packets under load, which means voice packets are being dropped too (unless [QoS](/blog/quality-of-service-explained) is properly configured and working).

If you are using an RMM platform that supports network monitoring, most of this data can be collected automatically and presented in dashboards. The key is actually configuring the monitoring profiles for voice-relevant metrics, not just the standard CPU/memory/disk checks that come out of the box.

### Synthetic testing: is the path actually working for voice?

All of the above methods are reactive to varying degrees. CDRs tell you about calls that already happened. RTP metrics tell you about quality on calls that already occurred. Network monitoring tells you about conditions right now, but not specifically how those conditions affect voice.

Synthetic testing fills the gap. Automated test calls placed on a schedule, using the actual voice path, that measure quality end to end without waiting for a real user to experience a problem.

The simplest form is a scheduled SIP OPTIONS ping or a periodic test registration to verify that the signaling path to the provider is up. More sophisticated approaches place actual calls between endpoints (or between an endpoint and a test service) and measure the audio quality of the resulting media stream.

This is an area where the tooling is still maturing for MSPs. Enterprise contact centers have had synthetic call testing for years, but the tools have historically been expensive and complex. Newer approaches, including what we are building at VoIP Test, use the browser's own audio stack to generate and measure test streams without requiring dedicated hardware or phone lines -- see [how MSPs use the VoIP quality test](/tools/voip-test/msp) for the client-facing workflow. The important thing is that some form of automated testing runs continuously, so you are not relying entirely on production calls to detect problems.

## Setting up alerts that matter

Having data is only half the problem. The other half is turning that data into alerts that actually get attention without drowning your team in noise.

### Thresholds, not absolutes

The most common mistake is setting alert thresholds at the boundary of "bad." If you alert when MOS drops below 3.6, you are alerting at the point where users are already complaining. You want to catch the trend before it reaches that point.

Set two tiers of alerts:

**Warning:** MOS below 3.9 for more than 10% of calls in a 4-hour window. Jitter sustained above 20ms for more than 15 minutes. Packet loss above 0.5% for more than 15 minutes. Bandwidth utilization above 80% of the link capacity during business hours.

**Critical:** MOS below 3.6 for any call. Jitter sustained above 40ms. Packet loss above 2%. Bandwidth utilization above 95%. Call completion rate below 90%.

Warning alerts go into a queue for review during your normal monitoring workflow. Critical alerts page someone. The specific numbers will need tuning for each client's environment (a client on a [DIA circuit](/blog/dedicated-internet-access) should have tighter thresholds than a client on shared cable), but the two-tier structure ensures you have early warning without alarm fatigue.

### Baselining

Before you can set meaningful thresholds, you need baselines. Run monitoring for two to four weeks without alerting to establish what "normal" looks like for each client. Some clients will have a natural pattern of slightly higher jitter during lunch hours because that is when everyone streams video. Some will have a consistent MOS of 4.1 because of their codec choice. Setting alerts without baselining leads to either constant false alarms or thresholds set so high they never trigger.

Document the baselines. You will need them later when troubleshooting, and they are invaluable in client reviews for showing improvement or justifying infrastructure recommendations.

### Correlation

A MOS alert is useful. A MOS alert that also shows you that bandwidth utilization spiked at the same time is actionable. Build your monitoring so that when a quality alert fires, the technician responding can immediately see the related network metrics for the same time window.

Most monitoring platforms support dashboard views that overlay multiple metrics on the same timeline. If yours does not, at minimum ensure that timestamps are consistent across your CDR data, RTP quality reports, and network monitoring so you can manually correlate events.

## Metrics that matter versus noise

Not every number your monitoring tools produce is worth watching. Focus on the metrics that directly predict user experience, and deprioritize the ones that are technically interesting but rarely actionable.

**Worth watching:**
- MOS per call and trending over time
- Jitter (average and peak) per call and trending
- Packet loss percentage per call and trending
- Bandwidth utilization as a percentage of link capacity
- Call completion rate (outbound)
- Average call duration (watch for downward trends)
- Registration failures (phones failing to register with the PBX/provider)

**Interesting but secondary:**
- Codec distribution (useful for troubleshooting, not for alerting)
- SIP response code distribution (useful for diagnosing [specific SIP problems](/blog/common-sip-problems), not for daily monitoring)
- Individual call setup time (unless it is dramatically increasing)

**Usually noise:**
- Raw packet counts
- Total call minutes (billing metric, not quality metric)
- Individual ping responses (trend the averages, not the individual probes)

The goal is a monitoring profile that a technician can review in five minutes and know whether a client's voice environment is healthy. If reviewing the dashboard takes 30 minutes and requires interpreting 40 different metrics, it will not get reviewed.

## Building a quality dashboard for client reviews

Here is where proactive monitoring starts paying for itself in client retention and upsell opportunities.

Build a simple monthly or quarterly quality report for each voice client. It does not need to be elaborate. A one-page summary with the following is enough:

**Quality summary.** Average MOS for the period, percentage of calls above 4.0, percentage below 3.6. A trend line showing MOS over time. If quality is stable and good, this is a reassurance data point. If quality has been declining, this is your evidence for recommending action before it becomes a problem the client notices.

**Availability.** Total calls placed and received. Completion rates. Any outages or incidents and how they were resolved. This demonstrates that you are watching and that the system is performing.

**Capacity utilization.** Peak concurrent calls versus available trunk capacity. Peak bandwidth utilization versus link capacity. This is where you plant the seed for [capacity planning](/blog/msp-capacity-planning) conversations. "You hit 22 concurrent calls last month and your trunk group supports 25. If your team grows, we should talk about adding capacity before it becomes a constraint."

**Recommendations.** Any changes you recommend based on the data. Maybe QoS needs tuning because a new application is competing with voice traffic. Maybe the ISP has been showing intermittent latency spikes that warrant a conversation. Maybe everything is fine and the recommendation is "no changes needed," which is itself a valuable statement that reinforces the quality of the service.

This report serves multiple purposes. It demonstrates the value of your managed voice service in terms the client can understand. It creates a natural cadence for infrastructure conversations that are proactive rather than reactive. And it gives you documented evidence of quality trends that is invaluable when [troubleshooting](/blog/msp-troubleshooting-voice-quality) a problem, since you can show exactly when quality started to degrade and what changed in the environment at that time.

## Practical implementation

If you are starting from zero, here is a practical path to getting monitoring in place.

**Week one.** Enable CDR collection from your PBX or hosted platform. Most platforms log CDRs by default; you just need to export them or connect to the database. Set up a basic spreadsheet or script that calculates daily completion rates and average duration. This alone will catch gross failures.

**Week two.** Set up network monitoring on the client's router and switches. SNMP polling for bandwidth utilization, interface errors, and uptime. Configure your RMM or monitoring platform to collect these metrics and build a dashboard that shows utilization trends over time.

**Week three.** Enable RTP quality reporting if your platform supports it. Pull MOS, jitter, and loss data per call and start building a baseline. If your platform does not report these natively, investigate whether there is a plugin, API, or third-party tool that can extract them.

**Week four.** Set up alerting based on the baselines you have established. Start with conservative thresholds (you can tighten them later) and route alerts to your monitoring queue. Review the first week of alerts with your team to calibrate. Too many false alarms means thresholds need adjusting.

**Ongoing.** Build the monthly quality report template and start delivering it at client reviews. Refine thresholds as you accumulate data. Add synthetic testing when tooling is available. Over time, your monitoring matures from "we check when something breaks" to "we know the state of every client's voice environment at all times."

## The competitive advantage

Most MSPs that offer voice are reactive. They deploy the system, hand over the phones, and wait for trouble tickets. The ones that differentiate themselves do so by demonstrating ongoing awareness and proactive management.

When you walk into a quarterly business review and show a client that their voice quality has been consistently above 4.0 MOS, that you caught and resolved a network issue before it affected calls, and that you are tracking capacity to anticipate when they will need to scale, you are demonstrating a level of operational maturity that justifies your monthly fee in a way that "we answer the phone when you have a problem" never will.

That is the difference between being a voice vendor and being a voice partner. And it starts with monitoring.

---

*Next up: [Handling the "My Phones Sound Bad" Call](/blog/msp-troubleshooting-voice-quality), covering troubleshooting voice quality from the MSP perspective, with the tools and access your end users don't have.*

---

### Part 12: Handling the "My Phones Sound Bad" Call

URL: https://voiptest.com/blog/msp-troubleshooting-voice-quality
Published: 2026-03-24
Tags: msp, voip-troubleshooting, call-quality, packet-capture, diagnostics

*The MSP's Guide to VoIP: Part 12 of 20*

Your phone rings. The client says "the phones sound terrible." Maybe they say it more colorfully than that. What they are telling you is that something about their voice experience has degraded to the point where they stopped tolerating it and decided to call you.

You have heard this call before if you have been running voice for any length of time. And the temptation is to jump straight into troubleshooting mode: start pinging things, pull up the PBX, check the router. But the MSPs that resolve these calls quickly and confidently have a system. They triage first, investigate second, and communicate third. This post walks through that system.

We have a whole [troubleshooting series](/blog/choppy-robotic-audio) on this site that walks through voice quality symptoms from the end user's perspective. That series is deliberately written for someone with limited tools and limited access, like a business owner or office manager trying to figure out why their phones sound bad. You are not that person. You have packet captures. You have PBX logs. You have CDR records. You have network monitoring data. You have the ability to make configuration changes and test the results in real time. The approach here is different because your toolkit is different.

That said, the symptom-by-symptom posts are a useful companion reference. When a client describes a specific symptom, the corresponding post in that series gives you the end-user perspective on what they are experiencing and the common causes. Cross-reference as needed.

## Triage: asking the right questions first

Before you touch a single tool, get answers to four questions. They take two minutes and save thirty.

### One phone or all phones?

This is the single most important question because it immediately determines where to look. If one phone sounds bad and everyone else is fine, the problem is almost certainly at the endpoint or the local connection to that endpoint: a bad cable, a [WiFi connection](/blog/wired-vs-wifi-for-voip), a failing phone, a misconfigured codec. You do not need to investigate the WAN link, the trunking, or the provider.

If all phones sound bad, or a significant subset, the problem is further up the chain. The local network, the internet connection, the trunking, or the provider's infrastructure are all in scope.

If the answer is "a few phones but not all," ask which ones. Phones in the same physical area might share a switch, a cable run, or a WiFi access point. Phones in the same department might share a call path or a trunk group. Patterns in which phones are affected narrow the investigation before it begins.

### Internal calls, external calls, or both?

This question separates the voice platform from the network path. If [internal calls](/blog/internal-vs-external-calls) between extensions sound fine but external calls sound bad, the local network and phone hardware are probably clean. The problem is in the path from the PBX to the PSTN: trunking, the internet connection, or the provider.

If internal calls also sound bad, the problem is local. Media for internal calls on most platforms stays on the local network (or at least within the PBX), so it never touches the internet or the trunking provider. Bad internal calls point to local network issues, PBX resource problems, or endpoint issues.

If only internal calls are bad but external calls are fine, that is unusual and often points to a PBX configuration issue: codec mismatch between internal extensions, transcoding under load, or a media handling problem on the PBX itself.

### Constant or intermittent?

A problem that is always present is easier to diagnose because you can reproduce it on demand. Run a [VoIP quality test](/tools/voip-test) right now, capture the traffic, and you will see the issue in the data.

An intermittent problem requires a different approach. You need to know when it happens. Ask the client for specific times, specific calls, specific phone numbers if possible. "It was bad yesterday afternoon" is useful. "It's been bad for a while" is not. Push for specifics: dates, times, which extensions, which external numbers. You will need this to pull the right CDRs and correlate with network monitoring data.

If the problem follows a time-of-day pattern (fine in the morning, bad after lunch), that is a strong indicator of bandwidth contention. See the post on [afternoon call quality degradation](/blog/afternoon-call-quality) for the common causes. If it correlates with a specific activity (bad during the weekly all-hands video call, bad when the accounting team runs month-end reports to the cloud), that tells you exactly what is competing for bandwidth.

### When did it start?

"It has always been like this" and "it started last Tuesday" are two very different investigations. If it started at a specific time, you need to know what changed at that time. New equipment installed? ISP maintenance? Software update on the PBX? New employee onboarded with bandwidth-hungry applications? A firmware update pushed to the phones?

If the client says it has always been bad, that might be true (which points to a systemic issue like insufficient bandwidth or missing [QoS](/blog/quality-of-service-explained)), or it might mean they only recently decided to complain about a gradually worsening problem. Check your [monitoring data](/blog/msp-proactive-monitoring) for the quality trend. If you have been tracking MOS scores, you can see exactly when quality started to decline, even if the client cannot pinpoint it.

## Investigation: using your tools

With the triage answers in hand, you know where to look. Now you look.

### Pull the CDRs

Start with the specific calls the client complained about. If they gave you timestamps and extensions, pull those CDRs. Look at the call duration, the completion status, and most importantly, the quality metrics if your platform records them per-call.

Many platforms attach RTP quality statistics to each CDR: MOS, jitter, packet loss, codec used. If the CDR shows a MOS of 3.2 with 4% packet loss on the calls the client flagged, you have confirmed the quality problem and you know the proximate cause is packet loss. You can use the [MOS Explorer](/tools/mos-explorer) to understand exactly how those loss and jitter numbers translate to the MOS the user experienced. The question becomes: where in the path is the loss occurring?

Also pull CDRs for the same time period from other extensions. If the flagged extension shows poor quality but other extensions at the same time show clean metrics, the problem is localized. If all extensions show degradation at the same time, the problem is shared infrastructure.

### Check your network monitoring

If you set up monitoring as described in the [previous post](/blog/msp-proactive-monitoring), you have bandwidth utilization, latency, and interface statistics for the client's network. Pull the data for the time window when the quality was bad.

What you are looking for:

**Bandwidth saturation.** Was the upload link at or near capacity during the problem period? If upload utilization was at 90% when the calls sounded bad and at 40% when they sounded fine, you have your answer. The fix is either better QoS configuration, bandwidth management to throttle non-voice traffic, or a circuit upgrade.

**Latency spikes.** Did latency to the VoIP provider's servers spike during the problem period? Compare to your baseline. If normal latency is 25ms and it was 150ms during the problem, something in the path changed. Check if the ISP had a maintenance event or a routing change.

**Interface errors.** Are the switch ports or router interfaces showing increasing error counters? CRC errors, input errors, and output drops all indicate problems. CRC errors on a switch port often mean a bad cable. Output drops on the router's WAN interface mean the outbound queue is overflowing, which is a QoS or bandwidth issue.

### Run a packet capture

When CDRs and monitoring narrow the problem but do not definitively identify the root cause, [packet captures](/blog/what-packet-capture-tells-you) tell the rest of the story. A capture on the relevant network segment shows you exactly what is happening at the packet level.

For voice quality issues, you want to capture the RTP stream. Most packet analysis tools (Wireshark being the standard) can decode RTP streams, display per-packet timing, calculate jitter, identify lost sequence numbers, and even play back the captured audio so you can hear the degradation yourself. If you have a pcap file from the capture, you can also run it through a [PCAP Analyzer](/tools/pcap-analyzer) to extract the voice quality metrics without manually navigating Wireshark's RTP analysis dialogs.

Where you capture matters:

**At the phone.** Capture at the switch port mirroring the phone's traffic. This shows you what the phone is sending and receiving. If the RTP stream leaving the phone is clean (consistent packet timing, no gaps) but the stream arriving at the phone has gaps or irregular timing, the problem is in the network between the phone and whatever is sending the media.

**At the router.** Capture on the LAN side of the router to see traffic after it has crossed the local network but before it hits the WAN. Compare this to a capture at the phone to isolate whether the local network is introducing degradation.

**At the PBX (if on-premises).** For self-hosted PBX systems, capture at the PBX to see the media streams it is handling. This tells you whether the PBX is receiving clean audio from the trunk provider and whether it is sending clean audio to the endpoints.

Comparing captures at multiple points in the path is the most definitive way to identify where degradation is being introduced. If the stream is clean at point A and degraded at point B, the problem is between A and B.

### Check the PBX

For self-hosted or on-premises PBX systems, check the platform's health during the problem period. High CPU utilization on the PBX can cause audio processing issues, especially if the system is doing transcoding (converting between codecs). A PBX that is transcoding 20 concurrent calls on hardware rated for 15 will produce exactly the kind of intermittent quality problems that are hard to pin down.

Check registration status for the affected phones. A phone that is intermittently losing its registration and re-registering will have brief periods where calls fail or audio cuts out. Registration issues point to network connectivity problems between the phone and the PBX, or to issues with the PBX's registration handling under load.

For hosted platforms, you have less visibility into the platform's health, but most providers offer a status page and incident history. Check whether the provider reported any issues during the time window in question. If they did not, that does not mean the problem was not on their end. It means they did not detect or acknowledge it. Provider-side investigation is covered in [post 14](/blog/msp-vendor-relationships).

### Check SIP signaling

If the quality problem involves calls failing to connect, dropping unexpectedly, or exhibiting [one-way audio](/blog/one-way-audio), the issue may be in the SIP signaling rather than (or in addition to) the RTP media. Pull the [SIP traces](/blog/reading-a-sip-trace) for the affected calls.

SIP traces show the entire call setup negotiation: INVITE, SDP offer/answer, codec selection, media port negotiation, and session timers. Common signaling-related quality issues include:

- Codec mismatch causing unexpected transcoding
- SDP negotiation selecting a low-quality codec when a better option was available
- [NAT traversal problems](/blog/common-sip-problems) causing media to flow through an indirect path
- Session timer expiration causing [calls to drop after a set time](/blog/calls-dropping-after-set-time)

Reading SIP traces is a skill that takes practice, but it is one of the most valuable diagnostic capabilities your team can develop. The [reading a SIP trace](/blog/reading-a-sip-trace) post covers the mechanics.

## The most common root causes

After years of troubleshooting voice quality for MSP clients, certain root causes come up far more often than others. In rough order of frequency:

**Bandwidth saturation without QoS.** The client's internet connection is getting fully utilized during business hours, and voice traffic is competing with everything else for bandwidth. This is the single most common cause of intermittent voice quality problems in small business environments. The fix is proper [QoS configuration](/blog/quality-of-service-explained) on the router to prioritize voice traffic, combined with bandwidth management policies for non-critical traffic. In some cases, the connection itself is undersized and needs upgrading.

**WiFi.** Phones or softphones on wireless connections experience jitter and loss from the inherent variability of the wireless medium. This was covered extensively in the [wired vs WiFi](/blog/wired-vs-wifi-for-voip) post. The fix is straightforward: wire the phones. If that is not possible, optimize the wireless environment for voice.

**Bad cables or switch ports.** A single bad Ethernet cable or a failing switch port introduces packet errors that affect the connected phone. These are easy to miss because the phone might work fine for data (web browsing is tolerant of occasional retransmissions) while voice quality suffers. The fix is replacing the cable or moving to a different switch port.

**ISP issues.** The internet connection itself is experiencing latency spikes, jitter, or packet loss. This can be caused by congestion on a shared connection (especially [cable](/blog/afternoon-call-quality)), a degrading last-mile connection, or routing changes in the provider's backbone. This is harder to fix because you don't control the infrastructure, but having data showing the problem is on the ISP side gives you the evidence needed to escalate. A client on a [DIA circuit](/blog/dedicated-internet-access) with an [SLA](/blog/sla-contract-language) has contractual leverage here.

**PBX resource exhaustion.** The on-premises PBX is running out of CPU, memory, or concurrent call capacity. This typically manifests as intermittent quality problems that correlate with call volume peaks. The fix is either optimizing the PBX configuration (reducing unnecessary transcoding, disabling unused features) or upgrading the platform.

**Provider-side issues.** The VoIP provider's infrastructure is the source of the degradation. This is less common than local issues but does happen, especially with lower-cost providers that oversubscribe their infrastructure. Diagnosing and resolving this requires working with the provider, which is the subject of [post 14](/blog/msp-vendor-relationships).

## Communicating findings to the client

Finding the root cause is half the job. The other half is explaining it to the client in terms that are accurate, understandable, and actionable.

Clients do not care about MOS scores, jitter buffers, or DSCP markings. They care about why their phones sound bad and what you are going to do about it. Translate your technical findings into business language.

Instead of: "Your RTP streams are showing 3% packet loss due to bandwidth saturation on the WAN uplink during peak hours, and your router is not configured with QoS to prioritize EF-marked traffic."

Say: "Your internet connection is getting overloaded during your busiest hours, and right now the phones are competing with everything else for bandwidth. We need to configure your router to give phone traffic priority so it gets through even when the connection is busy. That should resolve the quality issues without changing your internet plan."

Be specific about what you found, what you are going to do, and what the expected outcome is. If the fix requires spending money (a circuit upgrade, new hardware), present the cost alongside the quality data. "Your current connection is running at 90% capacity during business hours. We can reconfigure the router to prioritize voice, which will help, but as your team grows you will need more bandwidth. Here is what an upgrade would cost."

Avoid blame language. "Your internet is too slow" makes the client feel like they bought the wrong thing. "Your connection was sized correctly when we set it up, and your team's usage has grown to the point where we need to plan the next step" positions you as a proactive partner managing their growth.

Document your findings and the resolution. You need this for your own records, but it also feeds into the quality reporting discussed in the [monitoring post](/blog/msp-proactive-monitoring). If the same client has the same problem again in six months, you want to be able to pull up the previous investigation and see what was found and what was done.

## Building the muscle

Voice troubleshooting is a skill that improves with repetition. Every quality investigation your team handles makes the next one faster. A few things accelerate this process:

**Post-incident reviews.** After resolving a quality issue, spend five minutes documenting what the symptom was, what the root cause was, and how it was identified. Build a knowledge base that your team can reference. Over time, this becomes a diagnostic shortcut: "intermittent choppy audio on external calls during afternoon hours" maps directly to "check for bandwidth saturation, verify QoS."

**Lab practice.** If you have a lab environment with a PBX and test phones, deliberately create quality problems and practice diagnosing them. Saturate the bandwidth and watch the MOS drop. Introduce jitter with a traffic shaper and listen to what it sounds like. This builds the pattern recognition that makes real troubleshooting faster.

**Cross-reference the symptom guides.** The [troubleshooting series](/blog/choppy-robotic-audio) on this site covers specific symptoms in detail: [choppy audio](/blog/choppy-robotic-audio), [one-way audio](/blog/one-way-audio), [echo](/blog/echo-on-voip-calls), [delay and talking over](/blog/audio-delay-talking-over), [static and buzzing](/blog/static-buzzing-humming), [calls dropping](/blog/calls-dropping-after-set-time). Each post describes the symptom from the user's perspective and lists the common causes. When a client describes a symptom, start with the corresponding guide to orient your investigation, then apply the MSP-level diagnostic tools described here.

The goal is to get to the point where hearing "my phones sound bad" triggers a systematic response rather than a scramble. Triage, investigate, diagnose, resolve, communicate, document. Every time.

---

*Next up: [Capacity Planning and Scaling](/blog/msp-capacity-planning), covering how to anticipate when a voice system needs to grow and present upgrades as proactive management rather than reactive firefighting.*

---

### Part 13: Capacity Planning and Scaling

URL: https://voiptest.com/blog/msp-capacity-planning
Published: 2026-03-25
Tags: msp, capacity-planning, scaling, bandwidth, trunk-capacity

*The MSP's Guide to VoIP: Part 13 of 20*

Nobody calls their MSP to say "things are working great, but I think we might be approaching the limits of our voice infrastructure and should plan for growth." What actually happens is the system hits a wall. Calls fail, quality degrades, trunks busy out. Now you are firefighting a problem that was predictable and preventable.

Capacity planning is one of those areas that separates MSPs running a voice business from MSPs running a voice sideline. It is not technically difficult. It requires no specialized tools beyond what you should already have from [monitoring](/blog/msp-proactive-monitoring). What it requires is the discipline to track the right metrics over time and the confidence to have the growth conversation with the client before they experience a failure.

This post covers what to watch, how to interpret the trends, and how to present upgrades as competent management rather than an upsell.

## The three capacity constraints

Every voice environment has three resources that can become bottlenecks: trunk capacity, bandwidth, and platform resources. Each one has different symptoms when exhausted and different lead times for resolution.

### Trunk capacity

Trunks determine how many simultaneous external calls the system can handle. Clients often still talk about this in terms of "lines," but [lines don't exist anymore](/blog/voip-lines-dont-exist); the real constraint is concurrent call capacity. Whether you are running [SIP trunks](/blog/sip-trunking) to an ITSP or channels on a hosted platform, there is a hard limit on concurrent calls to and from the PSTN. When every available trunk is in use and another call tries to go out (or come in), it fails.

The failure mode depends on the direction. Outbound calls get a fast busy or a "all circuits are busy" recording. Inbound calls get a busy signal at the carrier level, which means the caller hears busy and the client never even knows the call was attempted. This is the worst outcome because the client is losing calls they do not know about. Their customer calls, gets busy, and calls a competitor instead.

**What to monitor:** Peak concurrent calls versus total trunk capacity. Most PBX platforms and hosted providers report concurrent call counts in their dashboards or CDRs. Track the daily maximum, not the average. You care about the peak because that is when the system is closest to its limit.

**Healthy headroom:** A reasonable operating target (not a standard, but a defensible engineering choice) is to keep at least 20-30% of trunk capacity unused during peak hours. If a client has 20 SIP trunk channels and regularly hits 16 concurrent calls, they are at 80% utilization and one busy day away from dropped inbound calls. That is the time to act, not when they hit 20 and start missing calls. (Formal trunk sizing uses Erlang traffic models: offered traffic in erlangs against a target blocking probability, in the vocabulary of ITU-T E.600. But for a small business, tracking peak concurrent calls against capacity gets you the same decision with far less math. Whichever method you use, the inputs are yours to choose for the deployment, not values any standard hands you.)

**Growth trajectory:** Plot peak concurrent calls by week or month. If the peak is climbing steadily, extrapolate when it will hit the trunk limit. This gives you a timeline for the capacity conversation. "Your peak call volume has been growing about two concurrent calls per quarter. At this rate, you will hit your trunk limit in six months. We should add capacity now so we are ahead of it."

**Seasonal patterns:** Some businesses have predictable spikes: accounting firms during tax season, retail during holidays, landscapers in spring. If you know the client's business, you can anticipate the spike and add temporary or permanent capacity before it hits. This is the kind of proactive management that clients remember.

### Bandwidth

Every concurrent VoIP call consumes a predictable amount of bandwidth, predictable once you fix the codec, the packetization interval, and the encapsulation. The numbers people quote are worked examples, not constants. A representative G.711 call at 20 ms packetization over Ethernet runs roughly 87 kbps per direction once you add RTP, UDP, IP, and Layer-2 framing to the 64 kbps payload; the same codec at a different packetization interval, or inside a VPN tunnel, produces a different number (Cisco's voice bandwidth consumption guidance walks through the arithmetic). G.729 under the same 20 ms Ethernet assumptions lands around 31 kbps per direction. Opus varies more because its payload bitrate is configurable: typically 30-80 kbps all-in depending on configuration. A [Bandwidth Calculator](/tools/bandwidth-calculator) can help you model these numbers against a client's actual codec, packetization, and encapsulation rather than guessing from a table.

The math seems straightforward: 20 G.711 calls at 20 ms over Ethernet consume about 1.7 Mbps of upload bandwidth and 1.7 Mbps of download. That is a tiny fraction of most modern internet connections. So bandwidth should never be a problem for voice alone, right?

Wrong, because voice does not exist in a vacuum. It shares the internet connection with everything else the office does. And the issue is not total bandwidth. It is momentary congestion and the absence of [QoS](/blog/quality-of-service-explained) prioritization on most connections.

A 100 Mbps upload link that averages 40% utilization can still have microsecond-level bursts that hit 100%. During those bursts, if voice packets are queued behind a large data transfer, they arrive late or not at all. This is why monitoring average bandwidth utilization is necessary but not sufficient. You need to monitor peak utilization and, ideally, utilization in the priority queue if you have QoS configured.

**What to monitor:** Upload and download utilization on the WAN link, tracked over time. Focus on business hours. Track the 95th percentile utilization (the level that utilization stays below 95% of the time) rather than just the average, because the 95th percentile captures the bursts that affect voice quality.

**Healthy headroom:** The thresholds here are operating targets, not standards: pick them for the deployment and defend them with your own data. As a working rule: if 95th percentile upload utilization during business hours is above 70% of the link capacity, voice quality is at risk during peak moments. If it is above 85%, you are probably already experiencing intermittent quality issues during the busiest periods, even if the client has not connected the dots yet. Check your [monitoring data](/blog/msp-proactive-monitoring) for MOS trends that correlate with bandwidth peaks; the correlation in your own measurements is what makes the threshold meaningful.

**Growth factors:** Bandwidth consumption grows for reasons that have nothing to do with voice. A client that adopts a new cloud CRM, starts using video conferencing heavily, moves their file server to SharePoint, or hires five new employees is consuming more bandwidth even if their call volume stays flat. Track total bandwidth trends, not just voice bandwidth, because voice quality is affected by all traffic on the link.

**The upgrade conversation:** Bandwidth upgrades are one of the easier capacity conversations because the data tells a clear story. "Your internet connection is running at 85% capacity during your busiest hours, and that is when your calls sound the worst. Here is the quality data showing the correlation. Upgrading to a faster connection, or adding a second connection with SD-WAN, would give you headroom for growth and eliminate the quality issues."

If the client is on a shared connection like cable and the quality issues are not just about capacity but about the [inherent variability of shared infrastructure](/blog/afternoon-call-quality), this might also be the time to discuss moving to [DIA](/blog/dedicated-internet-access) for voice traffic.

### Platform resources

This applies primarily to on-premises or self-hosted PBX deployments, though hosted platforms have their own limits that manifest differently.

An on-premises PBX (whether it is FreePBX on a physical server, 3CX on a VM, or any other self-hosted platform) has finite CPU, memory, and I/O capacity. As call volume grows, the PBX consumes more of each. The symptoms of a PBX approaching its resource limits are subtle at first and dramatic later.

**Early signs:**

- Call setup latency increases. The time between dialing and hearing ringback gets slightly longer. This is the PBX taking more time to process the INVITE because it is busy handling other calls.
- Transcoding quality degrades. If the PBX is converting between codecs (for example, G.729 on the trunk side and G.711 on the extension side), transcoding is CPU-intensive. Under load, the PBX may start producing degraded audio on transcoded calls while non-transcoded calls sound fine.
- Registration delays. Phones take longer to register or re-register. During a power outage recovery, when all phones try to register simultaneously, the PBX struggles to handle the flood and phones sit unregistered for minutes.
- Voicemail processing slows down. Messages take longer to appear in email, or voicemail-to-text transcription falls behind.

**Late signs:**

- Calls fail with [SIP 500 or 503 responses](/blog/common-sip-problems). The PBX is too overloaded to process new calls.
- Audio glitches that correlate with call volume peaks. The PBX cannot process media fast enough and starts dropping RTP packets.
- The system becomes unresponsive. The web interface hangs, SSH sessions timeout, and management operations fail.

**What to monitor:** CPU utilization, memory utilization, and disk I/O on the PBX during peak call periods. Track concurrent calls versus the platform's rated capacity (which the vendor should document). If you are running the PBX as a VM, also monitor the hypervisor's resource allocation. A VM that is competing with other VMs for CPU cycles will show voice quality degradation under load even if the guest OS metrics look acceptable.

**Hosted platform limits:** If you are reselling a hosted platform, the capacity constraints are the provider's problem to manage, but the limits still exist. They manifest differently: the provider might throttle new registrations, rate-limit API calls, or experience degraded call quality across their platform during peak hours. Platform-wide degradation that follows peak hours tells you there is a time-correlated bottleneck or failure domain, which is worth escalating on its own terms. It does not tell you which one: call-processing or media capacity, an upstream carrier, a peering link, a software limit that only bites under load, or a routing change applied during busy hours all present the same way from outside. Treat [capacity](/blog/voip-overbooking) as one hypothesis among those and ask the provider for utilization data covering the affected windows, rather than leading with a diagnosis you cannot substantiate. You have less visibility into these limits, which is why the [vendor relationship](/blog/msp-vendor-relationships) and the quality of their platform monitoring matters.

## Anticipating growth

The best capacity planning is not reactive to trends. It is informed by business context. You know things about the client's business that a monitoring dashboard cannot tell you.

**Hiring plans.** If a client tells you they are hiring ten people next quarter, that is ten more phones, ten more concurrent call slots needed, and proportionally more bandwidth consumed. Don't wait for those people to start and then discover the trunks are maxed out. Add the capacity before the new hires arrive. This is basic managed services discipline applied to voice.

**Office changes.** A client opening a second location, consolidating two offices, or moving to a larger space all have voice capacity implications. New locations need their own internet connections and network infrastructure [assessed and prepared](/blog/msp-network-assessment). Consolidations might temporarily double the call volume on a single system. Moves are covered in detail in the office move series, but the capacity implications are worth flagging here.

**Business growth.** A client whose revenue is growing is almost certainly generating more phone calls. Sales teams call more prospects. Support teams handle more customer calls. Seasonal businesses have predictable spikes. Understanding the client's business cycle helps you anticipate capacity needs before the metrics show them.

**Technology changes.** A client that adopts video conferencing, moves to cloud-based applications, or starts supporting remote workers is changing their bandwidth profile. A client deploying [AI voice agents](/blog/ai-voice-agents-sip) is an even sharper example: automated agents can spike from idle to hundreds of concurrent calls in seconds, a pattern that traditional capacity models do not anticipate. These changes affect voice capacity indirectly but meaningfully. The [network preparation](/blog/msp-network-preparation) work you did before the initial deployment may need revisiting as the client's technology stack evolves.

## When to add what

Knowing that capacity needs to increase is the first step. Knowing which resource to increase, and how, is the second.

### Adding trunk capacity

This is usually the simplest capacity change. Adding SIP trunk channels with most ITSPs is an account change. You request additional concurrent call capacity, and it is activated within hours or days. Some providers charge per channel, some include a pool of channels in their pricing, and some scale automatically. Know your provider's model so you can quote the cost quickly when the need arises.

For hosted platforms, adding trunk capacity might mean upgrading the client's plan tier or adding a trunk group. Check the provider's pricing and any minimum commitment requirements.

The lead time for trunk capacity changes is usually short (days), so you can be somewhat reactive here. But "somewhat reactive" means adding capacity when you see the trend approaching the limit, not when the client reports that calls are failing.

### Upgrading internet

This has a longer lead time and is more disruptive, so plan further ahead. Upgrading from a 100 Mbps cable connection to a 500 Mbps connection might take a few days if the ISP can provision it on the existing infrastructure. Moving from cable to [DIA](/blog/dedicated-internet-access) might take 30 to 90 days depending on whether the circuit needs to be built. Adding a second connection for [redundancy](/blog/redundancy-failover) or SD-WAN involves procurement, installation, and configuration.

Start the bandwidth upgrade conversation when 95th percentile utilization consistently exceeds 70% during business hours and the trend is upward. This gives you time to evaluate options, get quotes, and implement the upgrade before utilization reaches the point where quality degrades.

### Scaling the platform

For on-premises PBX systems, scaling might mean adding CPU and memory to a VM, migrating to a larger server, or moving to a clustered deployment. These changes involve downtime for the voice system, which means scheduling a maintenance window, communicating with the client, and having a rollback plan.

For hosted platforms, scaling might mean moving to a higher tier, migrating to a different platform entirely, or splitting the client across multiple instances. The lead time and complexity depend entirely on the provider.

The decision to scale the platform versus migrate to a different platform is a judgment call that depends on cost, capability, and the client's trajectory. A platform that serves a 30-person office well might not be the right platform for the same company when they reach 150. This is a larger conversation that involves evaluating the platform's roadmap, pricing at scale, and whether the features the client needs at that size are available. Platform selection criteria are covered in [post 5](/blog/msp-choosing-voip-platform).

## Presenting upgrades proactively

This is where many MSPs struggle, not because the technical analysis is hard, but because they are uncomfortable having cost conversations. It feels like upselling. It feels like asking the client to spend more money.

Reframe it. You are not selling them something. You are managing their infrastructure. Part of managing infrastructure is anticipating when it needs to grow and presenting that information with enough lead time that the client can budget and plan, rather than making emergency purchases under duress.

The formula is:

**Here is what the data shows.** "Your peak concurrent calls have been growing steadily and you are now routinely using 85% of your trunk capacity during your busiest hours."

**Here is what happens if we do nothing.** "When you hit 100%, inbound callers will get a busy signal instead of reaching your team. You won't know the call was attempted."

**Here is what I recommend.** "We add ten trunk channels, which gives you headroom for the next 12-18 months based on your current growth rate. The cost is $X per month."

**Here is the timeline.** "I'd like to make this change within the next 30 days, before the busy season."

This positions you as the professional who is watching their systems and planning ahead. The client does not feel sold to; they feel managed. There is a significant difference, and it is the difference between a client who sees your fee as a cost and a client who sees it as a value.

If you have been delivering quality reports as described in the [monitoring post](/blog/msp-proactive-monitoring), the capacity data is already part of the conversation. The upgrade recommendation is a natural extension of the data you have been presenting, not a surprise upsell dropped into a random meeting.

## The cost of not planning

When capacity is not planned, it is reacted to. And reactive capacity changes are universally more expensive, more disruptive, and more damaging to the client relationship.

A trunk capacity shortage that causes missed inbound calls for a day costs the client real business. An internet connection that is saturated to the point of [unusable voice quality](/blog/choppy-robotic-audio) for a week costs them patience and confidence in your management. A PBX that crashes under load during a Monday morning call spike costs them a morning of productivity and costs you a weekend of emergency work.

Beyond the direct cost, reactive capacity management undermines the managed services value proposition. The whole point of managed services is that someone is watching, planning, and preventing problems. If every capacity issue is a surprise, the client starts to wonder what they are paying for.

Proactive capacity planning, by contrast, reinforces the value proposition every time you have the conversation. "We've been tracking this, we saw it coming, here's the plan" is the most powerful statement an MSP can make. It demonstrates competence, builds trust, and creates the kind of long-term partnership that drives retention and referrals.

## A simple capacity planning checklist

For each voice client, review these metrics quarterly (monthly for fast-growing clients). The flag thresholds below are example operating targets: adjust them to the client's growth rate and risk tolerance, and be ready to explain why you chose them:

- Peak concurrent calls versus trunk capacity. Flag if above 75%.
- 95th percentile bandwidth utilization during business hours. Flag if above 70%.
- PBX CPU utilization during peak call periods (on-prem only). Flag if above 70%.
- PBX memory utilization (on-prem only). Flag if above 80%.
- Average call setup time. Flag if increasing trend.
- Registration success rate during high-load periods. Flag if below 99%.
- Client headcount changes (planned or actual).
- New applications or services consuming bandwidth.

Each flagged item gets a recommendation: add capacity, optimize configuration, or monitor closely for another quarter. Document the review and include it in your quality report.

The entire review takes 15 to 20 minutes per client if your monitoring is set up correctly. That is a trivial time investment compared to the cost of a capacity-related outage, and it is the kind of disciplined operational practice that builds a genuinely sustainable voice business.

---

*Next up: [Vendor Relationships: Working With Hosted Providers and Trunk Carriers](/blog/msp-vendor-relationships), on being an effective client advocate when the problem is on the provider's side.*

---

### Part 14: Vendor Relationships: Working With Hosted Providers and Trunk Carriers

URL: https://voiptest.com/blog/msp-vendor-relationships
Published: 2026-03-25
Tags: msp, vendor-management, voip-provider, support, escalation

*The MSP's Guide to VoIP: Part 14 of 20*

At some point in every voice engagement, you will determine that the problem is not on the client's network, not in the local equipment, and not in anything you control. The problem is on the provider's side. Maybe it is the hosted PBX platform. Maybe it is the [SIP trunk](/blog/sip-trunking) carrier. Maybe it is somewhere in between. And now you need to get someone else to fix it, on someone else's timeline, while your client is staring at you expecting resolution.

This is one of the hardest parts of running a voice business. You are accountable to the client for the entire voice experience, but you do not control every piece of the infrastructure. Your ability to get providers to investigate and resolve issues quickly, with minimal back-and-forth, is a skill that directly affects your client satisfaction, your support costs, and your sanity.

This post is about building that skill. Not the soft stuff about "being nice to vendors" (though that matters too), but the practical mechanics of getting problems solved when the problem is not yours to solve directly.

## The information problem

The single biggest reason provider tickets drag on is insufficient information in the initial report. A ticket that says "client is experiencing poor call quality" gives the provider nothing to work with. They will respond with a request for more details, which you will provide, which they will use to ask more questions, and three days of back-and-forth later you still have not gotten to the actual investigation.

Compare that to a ticket that arrives with everything the provider needs to start investigating immediately. The difference in resolution time is measured in days, not hours.

Here is what a well-constructed provider ticket looks like for a voice quality issue:

**Account and site identification.** Your account number, the client's site, the specific trunk group or service instance affected. Providers manage thousands of accounts. Do not make them guess which one you are talking about.

**Specific call examples.** This is the most important element. Provide at least three calls that exhibited the problem. For each call, include:
- Date and time (with timezone)
- Calling number and called number
- Call-ID from the SIP headers if you have it (this is the unique identifier the provider uses to find the call in their systems)
- Duration
- What the user experienced (choppy audio, one-way audio, dropped call, etc.)

Call-IDs are worth their weight in gold. A provider's support engineer can search their logs by Call-ID and pull up the exact SIP transaction, RTP quality statistics, and routing path for that specific call within seconds. Without a Call-ID, they are searching by time range and phone number across potentially millions of CDRs, which takes longer and introduces ambiguity when multiple calls match the criteria.

If you have access to [SIP traces](/blog/reading-a-sip-trace) from your side, include the relevant snippets. This shows the provider what your system sent and received, which helps them determine whether the issue is in their processing or in the path between you.

**Quality metrics from your side.** If your monitoring shows [MOS scores](/blog/understanding-mos-scores), [jitter](/blog/what-is-jitter-and-why-it-matters), and [packet loss](/blog/understanding-voip-packet-loss) for the affected calls, include them. Running a [VoIP quality test](/tools/voip-test) from the client's network during the problem window gives you concrete numbers to attach to the ticket. "The following calls showed MOS below 3.2 with 4% packet loss as measured at our PBX" tells the provider exactly what you observed and gives them a specific metric to compare against their own measurements. If their side shows clean metrics but your side shows degradation, the problem is in the path between you, and that narrows the investigation significantly.

**Network path information.** A traceroute from the client's network to the provider's signaling and media servers, captured during the time the problem was occurring. This shows the provider the routing path and any intermediate hops where latency or loss may be occurring. It is not definitive (traceroute has well-known [limitations for voice diagnostics](/blog/diagnosing-voip-problems)), but it gives the provider's network team a starting point.

**What you have already checked.** Briefly list what you have ruled out on your side: local network is clean, bandwidth is not saturated, QoS is configured and verified, problem affects all calls not just one endpoint. This prevents the provider from sending you through a first-tier troubleshooting checklist that you have already completed. It also demonstrates that you have done your homework, which changes how their support team engages with you.

## Building the relationship before you need it

The time to build a relationship with your provider's support organization is not when you have an urgent ticket. It is during the quiet periods when everything is working.

### Know your account team

Most providers assign account managers or channel managers to their MSP partners. This person is your primary relationship at the provider, and they are your escalation path when normal support is not moving fast enough.

Make a point of having a regular check-in with your account manager, even if it is just quarterly. Understand their role, their authority, and their escalation options. Ask them how their support organization is structured. Find out if there is a dedicated partner support queue separate from the end-user support queue (many providers have this). Ask about any tools or portals available to partners that are not available to end users. Some providers give partners access to deeper diagnostics, direct access to tier 2 support, or expedited ticket routing.

### Know the support structure

Every provider's support organization has tiers. Tier 1 handles initial triage and common issues. Tier 2 handles complex technical problems. Tier 3 or engineering handles platform-level issues and code changes. Understanding this structure tells you where your ticket needs to get to and helps you write the initial report in a way that gets it escalated appropriately.

If your initial ticket is written at a tier 1 level ("calls sound bad, please investigate"), it will be handled at tier 1, which means basic troubleshooting steps you have already completed. If your initial ticket includes Call-IDs, quality metrics, SIP traces, and a clear description of what you have already ruled out, a competent tier 1 agent will recognize that this needs to go to tier 2 immediately.

Some providers allow partner accounts to submit tickets directly to tier 2. If yours does, use it.

### Provide feedback

When a provider resolves an issue well, tell them. When their support process was frustrating, tell them that too, but through the account manager rather than in the ticket. Providers track partner satisfaction, and your feedback influences how they allocate resources and prioritize improvements.

If you consistently provide clean, well-documented tickets and constructive feedback, you become a partner that the support team recognizes and prioritizes. This is not about getting special treatment. It is about building a professional relationship where both sides operate efficiently.

## Escalation paths

Despite your best efforts, some tickets stall. The provider's investigation is inconclusive, the suggested fix did not work, or the issue has been open for days without meaningful progress. You need an escalation path.

### When to escalate

Escalate when the normal support process has not produced results within a reasonable timeframe for the severity of the issue. What counts as reasonable depends on the impact:

- A complete outage (no calls in or out) should have active investigation within the hour and resolution within the provider's committed MTTR. If it does not, escalate immediately.
- Ongoing quality degradation affecting all calls should have investigation within 4-8 business hours and a root cause identified within 1-2 business days. If the provider is still asking basic questions after two days, escalate.
- Intermittent quality issues are harder to timeline because they require the provider to capture data during the problem window. But if the ticket has been open for a week with no progress, escalate.

### How to escalate

**First level: the account manager.** Contact your account manager and explain the situation: the ticket number, how long it has been open, what has been done so far, and what the impact on your client is. A good account manager will engage the support management team internally and get additional resources on the ticket.

**Second level: support management.** If the account manager is not effective (or if you do not have one), ask for the support manager or duty manager in the support organization. Be professional, be specific, and be clear about the business impact. "We have had a ticket open for five business days with no root cause identified. Our client is experiencing degraded call quality on approximately 30% of their external calls. This is impacting their ability to conduct business."

**Third level: executive contact.** For critical issues that have not been resolved through normal channels, escalate to the provider's leadership. This is a last resort and should be used sparingly, but every MSP should know who to contact at the executive level for their critical vendors. This information often comes from the account manager or from partner program documentation.

### Document the escalation

Every escalation should be documented: when you escalated, to whom, what was communicated, and what the response was. This documentation serves two purposes. First, it creates a record if the issue becomes a pattern and you need to evaluate whether the provider is meeting their commitments. Second, it provides evidence if you need to invoke [SLA remedies](/blog/sla-contract-language).

## Evaluating when a provider is not meeting expectations

Not every issue is a one-off. Sometimes the pattern of issues, the quality of support, or the reliability of the platform indicates a systemic problem that is not going to improve.

Here are the signals that a provider relationship may need to be reconsidered:

**Recurring issues without root cause.** If the same type of problem keeps happening and the provider cannot identify or resolve the underlying cause, their platform may have a fundamental limitation that they are unwilling or unable to address.

**Degrading quality trends.** If your [monitoring data](/blog/msp-proactive-monitoring) shows a gradual decline in call quality across clients on the same provider, and the decline does not correlate with any changes on your side, the provider's infrastructure may be [oversubscribed beyond what it can deliver at peak](/blog/voip-overbooking) or poorly maintained.

**Support quality decline.** If ticket resolution times are getting longer, if the quality of technical investigation is declining, or if you are seeing increased turnover in the support team (different person on every ticket, no continuity), the provider may be cutting costs in ways that affect service quality.

**Feature stagnation.** If the provider's platform has not evolved meaningfully in a year while competitors have added significant capabilities, the provider may be in maintenance mode, collecting revenue without investing in the product.

**Pricing changes without value.** If the provider raises prices without corresponding improvements in service, features, or support quality, the value proposition is eroding.

None of these signals in isolation means you should immediately migrate. But if multiple signals are present and the trajectory is downward, start evaluating alternatives. The cost of migration is significant, but the cost of staying on a declining platform is higher. It just accrues more slowly.

## Managing a provider migration

Migrating a client from one voice provider to another is one of the most complex operations in an MSP's voice business. It involves porting phone numbers, reconfiguring or replacing endpoints, retraining users, and maintaining service continuity during the transition. It is not a decision to make lightly, but when it is the right decision, having a plan makes the difference between a smooth transition and a disaster.

**Pre-migration evaluation.** Before committing to a migration, run a thorough evaluation of the new provider using the same criteria you applied when you [originally selected the platform](/blog/msp-choosing-voip-platform). Set up a test environment, place test calls, evaluate the admin interface, test the support process, and verify that the features the client depends on are available and work correctly. Discovering a feature gap after you have started the migration is extremely costly.

**Number porting.** Phone numbers are the most critical and most time-sensitive element of a migration. Number porting between carriers typically takes 7-14 business days for standard ports and longer for complex ports involving multiple carriers. Initiate the port request early and track it closely. A delayed or failed port means the client's phone numbers do not work on the new platform, which is an immediate business disruption.

**Parallel operation.** Where possible, run the new platform alongside the old one during the transition period. Configure the new system, provision the phones, and test everything before porting the numbers. When the port completes, the numbers move to the new platform and the old one can be decommissioned. This minimizes the cutover window and gives you a fallback if something goes wrong.

**Communication.** Tell the client what to expect. A provider migration will involve some period of adjustment: new phone interfaces, slightly different feature behavior, potentially a brief interruption during the number port. Set expectations clearly and provide a timeline. Surprises during a migration erode the trust you are trying to protect.

**Post-migration monitoring.** After the migration, increase your monitoring frequency for the first 30 days. Watch quality metrics, call completion rates, and user feedback closely. New platform configurations often need tuning. [Trunk settings](/blog/msp-trunk-configuration), codec preferences, [QoS markings](/blog/quality-of-service-explained), and call routing rules may all need adjustment based on real-world performance.

## The value of multiple provider relationships

One of the most strategically valuable things an MSP can do is maintain relationships with more than one voice provider. This does not mean splitting every client across two providers (though that has [redundancy](/blog/redundancy-failover) benefits). It means having evaluated, tested, and established accounts with at least two providers so that you have options.

When you have only one provider relationship, you are dependent on that provider for every client. If their pricing becomes uncompetitive, you absorb the margin hit or pass it to clients. If their support quality declines, your clients feel it. If they have a major platform outage, every one of your voice clients is affected simultaneously.

With multiple provider relationships, you can:

- Match clients to the provider whose strengths best fit their needs. A 10-person office has different requirements than a 200-seat contact center. One provider may excel at simple deployments while another handles complex multi-site configurations better.
- Negotiate pricing with leverage. When your provider knows you have alternatives, pricing conversations are more balanced.
- Migrate away from a declining provider without starting the evaluation process from scratch. You have already tested the alternative.
- Provide genuine redundancy for clients who need it. Primary service on one provider, failover to another.

The investment in maintaining multiple relationships is modest: a test account, periodic evaluation of new features, and an occasional call with the account manager. The value when you need it is substantial.

## The MSP as intermediary

The fundamental dynamic in the MSP voice business is that you are an intermediary. The client relies on you. You rely on the provider. When things go wrong, the client holds you accountable and you hold the provider accountable. This works well when the provider is responsive and capable. It becomes painful when they are not.

The skills that make this work are not primarily technical. They are organizational: knowing what information the provider needs before they ask for it, building relationships that give you access to escalation paths, monitoring quality so you detect problems early, and maintaining alternatives so you are never trapped.

The MSPs that struggle with vendor relationships are usually the ones that treat providers as interchangeable commodity suppliers. The ones that thrive are the ones that invest in the relationship, hold the provider accountable with data rather than frustration, and always have a plan B.

Your client chose you because they wanted one responsible party for their voice service. You chose your provider for the same reason. Make sure the relationship you have with your provider mirrors the one your client expects from you: responsive, data-driven, and proactive.

---

*Next up: [The Regulatory Landscape: What the FCC Considers a Voice Service Provider](/blog/msp-regulatory-landscape). The compliance section begins, covering what triggers VSP classification and why it matters to your MSP.*

---

### Part 15: Multi-Site Deployments

URL: https://voiptest.com/blog/msp-multi-site-deployments
Published: 2026-03-26
Tags: msp, multi-site, voip-architecture, vpn, failover

*The MSP's Guide to VoIP: Part 15 of 20*

Most of the series so far has focused on single-site deployments. One office, one internet connection, one set of switches and phones. The fundamentals are the same for multi-site, but the architecture decisions multiply. You are no longer just connecting phones to a PBX. You are connecting multiple networks across multiple locations into a system that feels like a single office to the people using it.

Multi-site voice is where the value of an MSP becomes undeniable to the client. The complexity of making extension dialing, call routing, and quality monitoring work across locations is well beyond what most businesses can manage on their own.

## Architecture options

There are three primary approaches to multi-site voice, and the right choice depends on the client's size, locations, platform, and budget.

### Single hosted PBX with phones at all sites

This is the simplest architecture and the one most MSPs should default to for small and mid-sized clients. All phones at all locations register to the same hosted PBX platform. Extension dialing works automatically because every phone is on the same system. Call routing, auto attendants, ring groups, and voicemail are centrally managed. There is no inter-site trunking to configure. There is no replication or synchronization to manage.

The platform provider handles the infrastructure. You handle the local network at each site and the phones. Each site needs its own internet connection with adequate bandwidth and quality for voice, its own voice VLAN and [QoS configuration](/blog/quality-of-service-explained), and its own provisioning for local phones. But the voice platform itself is shared.

The limitation is that calls between extensions at the same site still travel out to the hosted platform and back, which means they use internet bandwidth in both directions and are subject to whatever latency and quality the internet path provides. For most hosted platforms, this is a non-issue because the calls are routed efficiently and the added latency is negligible. But for clients with marginal internet connections at remote sites, it can be a factor.

### Separate systems with inter-site trunking

Each site has its own PBX (on-premises or hosted), and the PBXes are connected to each other via SIP trunks. Extension dialing between sites works through the inter-site trunk. Calls between sites are routed over a site-to-site VPN or directly over the internet between the PBX systems.

This approach provides local survivability. If the internet connection at one site goes down, the phones at that site can still make and receive calls through the local PBX (assuming it has its own trunk to the PSTN). Calls between sites are disrupted, but internal calls within each site continue to work.

The complexity is higher. You are managing multiple PBX systems, keeping their configurations synchronized (dial plans, extension numbering, voicemail access), and maintaining the inter-site SIP trunks. Extension number conflicts between sites need to be avoided through careful planning (site A uses 1xx, site B uses 2xx, etc.).

This model makes sense for clients where local survivability is a hard requirement, typically businesses where not having phones for even an hour causes significant operational or revenue impact.

### Hybrid approaches

Some deployments combine the two models. The main office runs an on-premises PBX with full PSTN connectivity. Remote offices register to the main PBX over a VPN, with a local SBC (session border controller) or survivability gateway that provides basic calling if the VPN goes down.

Other hybrids use a hosted platform as the primary system with on-premises gateways at key sites for local PSTN breakout, reducing the dependency on internet connectivity for external calls.

The right hybrid depends on the client's specific requirements, and the design process involves mapping each requirement (survivability, quality, cost, management simplicity) to an architectural component.

## Extension dialing and numbering

For a multi-site deployment to feel seamless, users need to dial extensions to reach people at other sites the same way they dial extensions for people in the same office. This requires a coherent numbering plan.

**With a single hosted platform**, this is automatic. All extensions are on the same system. Extension 201 at the main office and extension 305 at the branch are both reachable by dialing their extension number from any phone on the system.

**With separate PBX systems**, you need non-overlapping extension ranges and inter-site dial plan rules. If site A uses extensions 100 to 199 and site B uses 200 to 299, you configure each PBX's dial plan to route calls to the other site's extension range over the inter-site trunk. This also means that new extensions at any site must stay within the assigned range.

For larger deployments, a four-digit extension plan (site code + extension: 1201 for site 1 extension 201) provides more room to grow and makes it immediately clear which site an extension belongs to.

## Network considerations

Multi-site voice adds network requirements that do not exist in single-site deployments.

### Bandwidth per site

Every site needs enough upload bandwidth to support its voice traffic. The calculation is the same as for single-site: <a href="https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/7934-bwidth-consume.html" rel="nofollow noopener noreferrer" target="_blank">80 kbps per concurrent G.711 call</a> in each direction at the IP layer, or 87.2 kbps once Ethernet framing is counted at 20 ms packetization. Over a site-to-site VPN, tunnel overhead pushes it higher still, which is where the 100 kbps figure people quote comes from. Name the layer before you size anything, and model your own case with a [Bandwidth Calculator](/tools/bandwidth-calculator). A site with 10 concurrent calls needs roughly 1 Mbps of dedicated upload bandwidth for voice.

For remote sites with smaller internet connections, bandwidth becomes the primary constraint. A branch office with a 10 Mbps upload connection supporting 5 employees might seem adequate, but if those 5 employees are frequently on calls while also using cloud applications, the upload can become saturated. [QoS](/blog/quality-of-service-explained) at each site is mandatory, not optional.

If inter-site calls traverse a VPN, the bandwidth for those calls comes out of both sites' internet connections. A call from site A to site B uses upload bandwidth at site A and download bandwidth at site A for the return path, plus the corresponding upload and download at site B. So an inter-site call is counted twice in your planning, once at each site, where a call to an external number consumes capacity at one site only.

### Latency between sites

For inter-site calls that traverse the internet or a VPN, latency between sites matters. Two offices in the same city might see 5 to 15 milliseconds round trip between them. An office in New York and one in Los Angeles will see 60 to 80 milliseconds round trip in practice: the one-way propagation floor through fiber is only about 20 to 25 milliseconds, and the rest is routing and queuing. Watch the units here, because voice guidance is written one-way and measurement tools usually report round trip. Add routing overhead and encryption for VPN, and you might see 80 to 120 milliseconds.

Above [150 milliseconds one-way](https://www.itu.int/rec/T-REC-G.114/en), conversations begin to feel awkward (G.114 still treats the 150 to 400 millisecond band as acceptable provided planners understand the impact, and puts 400 milliseconds as the ceiling for general planning), with [people talking over each other](/blog/audio-delay-talking-over) because the delay makes it hard to gauge when the other person has stopped speaking. For most domestic multi-site deployments, this is not a problem. For international deployments (US to Europe, US to Asia), it can be.

Measure the latency between sites before deploying with a [VoIP quality test](/tools/voip-test) and factor the results into the architecture decision. If inter-site latency is high, a hosted platform where both sites register to servers that are geographically between them may provide better quality than direct inter-site trunking.

### Failover

What happens when one site's internet connection goes down? The answer depends on the architecture.

**Hosted platform with phones at all sites:** The site that loses internet loses all phone service. Other sites are unaffected. The mitigation is a [backup internet connection](/blog/redundancy-failover) at each site, which may or may not be justified depending on the site's importance.

**Separate PBX per site:** The site that loses internet loses connectivity to other sites and to calls that traverse the internet, but can still make and receive calls through local PSTN trunks (if the PBX has them). Internal calls within the site continue to work.

**Hosted platform with local survivability gateway:** The gateway detects the internet outage and activates local calling through a local PSTN connection. Functionality is limited (usually just basic inbound and outbound calling, no advanced features), but the phones are not completely dead.

For any multi-site deployment, document the failure modes for each site and ensure the client understands what happens when connectivity is lost. The expectation should be set during the deployment planning, not discovered during an outage.

## Common mistakes

Multi-site deployments have failure patterns that repeat across clients and MSPs. Knowing them saves time and credibility.

**Underestimating bandwidth at remote sites.** The main office has a fiber connection with 100 Mbps upload. The branch office has a cable connection with 10 Mbps upload. The branch gets the same VoIP deployment as the main office. Nobody checks whether 10 Mbps upload is enough when the branch staff is on calls, running cloud backups, and uploading files simultaneously. It is not. The branch has choppy calls every afternoon, and nobody connects it to the bandwidth constraint because the main office is fine.

**Not accounting for latency between distant offices.** If the two offices are in the same region, this is rarely a problem. If they are on different coasts or different continents, the latency is noticeable on calls and needs to be factored into codec selection and platform architecture.

**Assuming the same configuration works everywhere.** Each site has its own network equipment, its own internet connection, its own physical layout. The QoS configuration that works on the Cisco router at the main office does not directly translate to the Ubiquiti router at the branch. The VLAN setup on the HP switches at one site needs to be adapted for the Netgear switches at the other. Treat each site as its own deployment that shares a platform with the others, not as a copy of the first site.

**Neglecting remote site monitoring.** It is easy to monitor the main office because that is where you have the most visibility. Remote sites with smaller staff and less infrastructure get less attention. But remote sites are often more fragile, with less bandwidth, fewer redundancy options, and less on-site technical knowledge. Proactive monitoring at every site, not just headquarters, prevents problems from festering.

**Forgetting E911 at every location.** Each site needs its own [E911 address registered with the VoIP provider](https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-9/subpart-D/section-9.11). A phone at the branch office that dials 911 must send responders to the branch office, not to the main office. This is a life safety issue. Verify E911 registration for every location, test it, and update it when locations change. Per-site is the floor rather than the ceiling: for a multi-line phone system the requirement is a dispatchable location, which in a large building means floor or room granularity and not merely the street address, and those duties fall on whoever installs, manages, or operates the system, not only on the VoIP provider. E911 compliance at every location is not optional and carries both legal liability and life safety implications. Consult your telecom attorney about per-location regulatory requirements.

## Platform choice revisited

The [platform selection decision](/blog/msp-choosing-voip-platform) from earlier in the series gets more weight in multi-site scenarios.

Hosted platforms excel at multi-site because the provider handles the central infrastructure and inter-site connectivity is inherent (all phones register to the same platform). Adding a new site means deploying phones and network infrastructure at that site, not deploying and integrating another PBX.

On-premises PBX deployments become significantly more complex in multi-site because you are now managing multiple PBX systems, inter-site trunking, dial plan synchronization, and distributed administration. The operational cost of multi-site on-premises voice is substantially higher than multi-site hosted voice, and for most MSP-managed clients, the hosted model is the better fit.

The exception is when the client has requirements (survivability, data sovereignty, compliance) that mandate local infrastructure. In those cases, the additional complexity is the cost of meeting the requirement.

*Next up: [Contact Centers and High-Volume Voice](/blog/msp-contact-center), covering what happens when a client's needs go beyond a phone system into queue management, agent metrics, and call recording.*

---

### Part 16: Contact Centers and High-Volume Voice

URL: https://voiptest.com/blog/msp-contact-center
Published: 2026-03-26
Tags: msp, contact-center, acd, call-recording, queue-management, workforce

*The MSP's Guide to VoIP: Part 16 of 20*

> **Disclaimer:** This post is educational content about contact center deployment and compliance considerations for MSPs. It is not legal advice. Regulations change, interpretations vary, and your specific situation may differ from the general scenarios described here. Consult with a telecom attorney to determine how these regulations apply to your business.

There is a moment in most MSP-client relationships where someone asks for something that a regular phone system is not designed to do. They want to know how many calls were missed last Tuesday. They want calls routed to the agent who has been idle the longest. They want calls recorded for training purposes. They want a wallboard in the call center showing real-time queue statistics.

These are contact center requirements, and the distinction between a phone system with a queue feature and an actual contact center platform is one of the most important lines in voice services. Getting it right means delivering a solution that genuinely improves the client's operations. Getting it wrong means deploying a phone system that almost does what they need, which is worse than not doing it at all because it creates the expectation without delivering the result.

## The difference between a queue and a contact center

Most PBX platforms, hosted and on-premises, include some form of call queuing. Calls come in, if all agents are busy the caller waits in a queue, and when an agent becomes available the next call is delivered. Basic queue features include hold music, position announcements, and perhaps a timeout that sends the caller to voicemail if the wait exceeds a threshold.

This is fine for a business that receives moderate call volume and just needs an orderly way to handle peaks. A medical office with three receptionists, a small law firm, a landscaping company during spring. The queue smooths out the bumps.

A contact center is different in kind, not just degree. The contact center model assumes that managing call flow is a core operational function with dedicated staff, metrics, and management processes. It includes:

**Automatic Call Distribution (ACD)** with sophisticated routing that goes well beyond first-in, first-out. ACD is the engine that decides which agent gets which call, and the routing strategy is a business decision.

**Real-time monitoring** so supervisors can see what is happening right now: how many calls are in queue, which agents are available, which are on calls, how long the longest wait is.

**Historical reporting** so management can analyze performance over time: service level percentages, average handle times, abandonment rates, peak periods, agent utilization.

**Agent state management** so the system knows whether an agent is available, on a call, in after-call work, on break, or logged out, and routes calls accordingly.

**Recording and quality management** for compliance, training, and dispute resolution.

A PBX queue does not provide these things, or provides them only in a limited way that does not scale. If the client needs any three of the five items above, they need a contact center platform, not a PBX with a queue.

## ACD routing strategies

The routing strategy determines how the ACD selects which agent receives the next call. Different strategies suit different operations.

**Round robin.** Calls are distributed evenly across agents in a fixed order. Agent A gets the first call, agent B gets the second, agent C gets the third, then back to A. This is simple and ensures even distribution, but it does not account for agent availability or skill.

**Longest idle.** The call goes to the agent who has been waiting the longest since their last call. This produces the most even workload distribution and is the most common strategy for general-purpose queues.

**Skills-based routing.** Calls are routed to agents based on their skills. A Spanish-speaking caller gets routed to a bilingual agent. A technical support call gets routed to a tier-2 agent. A VIP customer gets routed to the senior team. Skills-based routing requires defining skill groups, assigning agents to groups, and configuring routing rules that match call attributes (dialed number, IVR selection, caller ID, time of day) to skill requirements. Before building a complex IVR tree, map the menu structure with an [IVR Planner](/tools/ivr-planner) to visualize the paths callers will follow and catch dead ends before they go live.

**Priority routing.** Certain calls jump the queue based on criteria: VIP customer, callback request, escalation from another queue. Priority routing can be combined with skills-based routing so that a high-priority call still goes to a qualified agent.

The choice of routing strategy is a business decision that the client's operations team should drive, with the MSP implementing and configuring it technically. The MSP should understand the options well enough to advise, but the business rules come from the people running the call center.

## Reporting

Contact center reporting divides into real-time and historical, and both are essential.

### Real-time metrics

Real-time data is typically displayed on a wallboard (a monitor or web dashboard visible to agents and supervisors) and includes:

- **Calls in queue:** How many callers are waiting right now.
- **Longest wait:** How long the longest-waiting caller has been in queue.
- **Available agents:** How many agents are ready to take a call.
- **Service level:** The percentage of calls answered within the target time (e.g., 80% of calls answered within 20 seconds: a widely used convention that falls out of [a staffing model](https://www.itu.int/dms_pub/itu-d/opb/stg/D-STG-SG02.16.2.1-2002-PDF-E.pdf), not a published standard).

These metrics tell supervisors whether the current staffing is adequate for the current call volume. If the queue is building and the longest wait is climbing, they need more agents on the phones now.

### Historical metrics

Historical reporting is used for planning, performance management, and identifying trends:

- **Service level over time:** Were staffing levels adequate each hour, each day, each week?
- **Average handle time (AHT):** How long does a typical call take, from answer to the end of after-call work? This is the key input for staffing models.
- **Abandonment rate:** What percentage of callers hang up before being answered? High abandonment indicates insufficient staffing or excessive wait times.
- **Average speed of answer (ASA):** How long does the average caller wait before being connected to an agent?
- **Peak periods:** When are call volumes highest? Are there patterns (Monday mornings, first of the month, after marketing campaigns)?

Historical data informs hiring decisions, scheduling, training priorities, and process improvements. Without it, the contact center is operating blind.

## Call recording

Call recording is a common requirement in contact centers, driven by compliance, training, quality assurance, and dispute resolution. The implementation details matter more than most people realize.

### Where recordings are stored

Recordings need to be stored securely and with appropriate retention. For cloud contact center platforms, the provider typically handles storage. For on-premises systems, recordings are stored locally or pushed to a file server or object storage. The storage requirements add up: a single G.711 call at 64 kbps generates approximately 0.5 MB per minute of recording (roughly 1 MB per minute when storing both sides separately). A contact center handling 500 calls per day averaging 5 minutes each produces about 1.25 GB of recordings per day on a single channel, or about 2.5 GB storing both sides separately, or roughly 50 to 75 GB per month depending on format and overhead.

Plan the storage, retention, and backup strategy before deploying recording. Running out of disk space and losing recordings is both an operational failure and, in regulated industries, a compliance violation.

### Compliance considerations

**PCI DSS.** If the contact center handles payment card data (credit card numbers, CVVs), [PCI DSS requires that sensitive authentication data not be retained in recordings after authorization](https://www.pcisecuritystandards.org/faqs/1210/). That is a rule about retention rather than a ban on recording, so pause-and-resume, DTMF suppression, and secure deletion straight after authorization are all compliant paths. Most compliant recording systems can pause recording during the payment portion of a call, either manually (the agent presses a button) or automatically (the system detects DTMF tones or integration with the payment system triggers a pause). This is a non-negotiable requirement for any business that processes payments over the phone.

**HIPAA.** Healthcare organizations that record calls containing protected health information (PHI) must ensure recordings are stored, transmitted, and accessed in compliance with HIPAA. This includes encryption at rest and in transit, access controls, audit logging, and Business Associate Agreements with any third party that handles the recordings.

**State recording laws.** Some states require all-party consent for call recording (all parties to the call must be informed and consent to recording), while others require only one-party consent. The client needs to understand the laws in their state and the states their callers are in, and configure appropriate recording announcements. [Washington](https://app.leg.wa.gov/rcw/default.aspx?cite=9.73.030) is worth calling out as an implementation detail rather than a legal footnote: where consent is obtained by announcement, the statute requires that the announcement itself be recorded, which is something the recording system has to be set up to do. This is a legal question, not a technical one, and the MSP should flag it rather than answering it.

## CRM and ticketing integration

A contact center that is not integrated with the client's CRM or ticketing system creates unnecessary manual work for agents. The key integrations are:

**Screen pop.** When a call arrives, the agent's screen automatically displays the caller's record from the CRM, pulled by matching the incoming caller ID to a customer record. The agent immediately knows who is calling and can see their history without asking. This reduces handle time and improves the caller's experience.

**Click-to-dial.** Agents can initiate outbound calls from within the CRM by clicking a phone number. The contact center system places the call and connects it to the agent's phone. This eliminates misdials and saves time.

**Automatic call logging.** After a call ends, the contact center system automatically creates a record in the CRM or ticketing system with the call details: caller, agent, time, duration, and optionally a link to the recording. This ensures that every interaction is documented without relying on agents to remember to log their calls.

Most cloud contact center platforms have pre-built integrations with major CRM systems (Salesforce, HubSpot, Zoho, ConnectWise, Autotask). On-premises systems typically require API integration work or third-party middleware.

## Infrastructure requirements

Contact centers have higher infrastructure demands than standard phone deployments because of the number of concurrent calls and the additional services running alongside voice.

**Bandwidth.** A contact center with 30 agents might have 25 to 30 concurrent calls at peak. Using G.711 at 87.2 kbps per call on Ethernet, that is about 2.2 to 2.6 Mbps of upload bandwidth just for voice; call it 3 Mbps once you allow headroom. Add screen sharing, CRM web traffic, recording upload, and agent desktop activity, and the total bandwidth requirement climbs. If the client adds [AI voice agents](/blog/ai-voice-agents-sip) to handle first-tier calls, the math changes again: automated agents generate concurrent call volumes and traffic spikes that human staffing models do not predict. [Dedicated internet access](/blog/dedicated-internet-access) is often appropriate for contact center locations because it provides guaranteed bandwidth and real SLAs.

**PoE budget.** Every agent desk has a phone, and possibly a headset base station that also requires PoE. Conference rooms and common areas add more devices. Size the switch PoE budget for the full agent count plus growth.

**QoS.** QoS is critical in contact centers because the high volume of concurrent calls amplifies the impact of any congestion. A quality problem that causes a brief hiccup on one call in a 10-phone office causes hiccups on 25 calls simultaneously in a contact center. The QoS configuration needs to accommodate the higher concurrent call count.

**Redundancy.** A contact center that goes down means the business is not taking calls. For many businesses, not taking calls means not generating revenue. Internet redundancy, power redundancy (UPS for network equipment and phones), and platform redundancy (cloud platforms with multi-region failover) are appropriate for contact center deployments in a way that might be overkill for a standard office.

## When to deploy a dedicated platform

The decision between stretching a standard PBX and deploying a dedicated contact center platform usually comes down to a few questions:

Does the client have dedicated staff whose primary job is answering calls? If yes, they need a contact center.

Does the client need real-time visibility into queue performance? If yes, they need a contact center.

Does the client need historical reporting for staffing and performance management? If yes, they need a contact center.

Does the client need skills-based routing? If yes, they need a contact center.

If the answer to all of these is no, a PBX with a basic queue feature is probably sufficient.

For cloud contact center platforms, the MSP typically resells or co-manages the platform (similar to the [service models](/blog/msp-voice-service-models) discussed earlier in the series). For on-premises contact center deployments, the MSP is taking on a significant implementation and management commitment.

The contact center space is one where the MSP's value is highest. The client is unlikely to have the expertise to evaluate, deploy, configure, and maintain a contact center platform on their own. The MSP that can do this well has a deeply embedded, high-value relationship with the client.

*Next up: [The Regulatory Landscape: What the FCC Considers a Voice Service Provider](/blog/msp-regulatory-landscape), where the compliance section begins, covering what MSPs need to know about voice service regulation.*

---

### Part 17: The Regulatory Landscape: What the FCC Considers a Voice Service Provider

URL: https://voiptest.com/blog/msp-regulatory-landscape
Published: 2026-03-27
Tags: msp, fcc, vsp, regulatory, compliance, telecom-law

*The MSP's Guide to VoIP: Part 17 of 20*

> **Disclaimer:** This post is educational content about telecommunications regulatory classification and Voice Service Provider obligations. It is not legal advice. Regulations change, interpretations vary, and your specific situation may differ from the general scenarios described here. Consult with a telecom attorney to determine how these regulations apply to your business.

Back in [Post 2](/blog/msp-voice-service-models), we walked through the spectrum of voice service models (referral, white-label resale, co-managed, and full stack), and at each level, we flagged that your regulatory exposure increases as you move deeper into the stack. We said we would come back to this. Here we are.

This is the part of the series where a lot of MSPs start to get uncomfortable, because the regulatory landscape around voice services in the United States is not something most IT professionals were trained on, and it does not map cleanly onto the way MSPs think about their business. You think of yourself as a managed services provider. You sell IT services. Maybe you resell some cloud subscriptions. The idea that you might be a telecommunications provider subject to FCC oversight feels like it belongs to a different industry.

But the FCC does not care what you call yourself. It cares what you do. And depending on how you have structured your voice offering, what you do might make you a Voice Service Provider in the regulatory sense, with all the obligations that come with it.

## What is a Voice Service Provider

The term "Voice Service Provider" as used by the FCC has a specific meaning that extends well beyond what most people think of as a phone company. In the context of the rules around robocall mitigation and STIR/SHAKEN (which we will cover in the next two posts), the definition is more precise than "anyone who touches a call": a voice service provider furnishes voice service to end users, interconnected with the PSTN and using North American Numbering Plan resources. Intermediate providers are a distinct category: entities that carry or process traffic they neither originate nor terminate. The FCC's Robocall Mitigation Database filing guidance (DA 26-72) walks through both definitions, and they reach plenty of entities that would never traditionally think of themselves as telecommunications carriers.

The FCC's key term here is "interconnected VoIP," meaning VoIP service that connects to the PSTN. If you are offering end users a VoIP service that can place calls to and receive calls from regular phone numbers on the public telephone network, you are offering interconnected VoIP, and the obligations that come with that classification apply regardless of your company's size or how you describe your business.

The traditional telecom world had relatively clear boundaries. You were either a carrier or you were not. You either had switching equipment and interconnection agreements and tariffs, or you were a customer. VoIP blurred those boundaries significantly, because the cost of originating and terminating calls dropped to near zero, and the technical barrier to entry collapsed. Suddenly, any company with a SIP trunk and a PBX could originate calls onto the PSTN. And the regulatory framework has been evolving to catch up with that reality.

For MSPs, the critical question is not "am I a phone company" in the traditional sense. The question is "am I doing things that the FCC considers voice service provision." Those are different questions, and the second one catches more entities than you might expect.

## The spectrum of involvement

Not every MSP that touches voice is a VSP. Your regulatory exposure depends on where you sit on the spectrum of involvement, and the boundaries are not always crisp. Let's walk through the range.

### Referring clients: not a VSP

If your voice involvement consists of introducing clients to a hosted VoIP provider, collecting a referral fee, and stepping back, you are not providing voice services. You are making an introduction. The provider handles everything: provisioning, billing, support, trunking, regulatory compliance. Your regulatory exposure is effectively zero.

This is one of the genuinely nice things about the referral model, as we discussed in [Post 2](/blog/msp-voice-service-models). Whatever its limitations in terms of margin and client control, it keeps you cleanly on the IT services side of the line.

### Reselling under a provider's authority: it depends

The white-label resale model is where the picture gets murkier. When you resell a hosted VoIP platform under your brand, the question of who is the voice service provider depends on how the arrangement is structured.

In many white-label arrangements, the wholesale provider retains the role of provider of record. They hold the FCC filings, they manage the trunking, they handle E911 provisioning, they contribute to the Universal Service Fund. You are their sales channel and support front-end, but from a regulatory perspective, they are the entity providing voice services to the end user. Your agreement with them spells this out (or should).

In other arrangements, particularly as you move toward greater independence and higher margins, the regulatory responsibility may shift partially or fully to you. If you are the entity that bills the end customer for voice services, if you control the customer relationship, if you make representations to the customer that you are their phone provider, regulators may view you as a voice service provider regardless of who operates the underlying infrastructure.

The key factors that regulators and courts have considered include: who the end customer believes their provider is, who bills the customer, who controls the service, and who has the ability to make changes to the customer's service. If the answers to those questions point to you, the fact that someone else runs the platform may not insulate you from VSP classification.

### Originating traffic on your own trunking: almost certainly a VSP

If you operate your own PBX infrastructure and contract directly with SIP trunk providers for PSTN connectivity, you sit much closer to the FCC's definition. This is the full-stack model from [Post 2](/blog/msp-voice-service-models), and it is the scenario with the clearest regulatory implications.

Be careful about the reasoning, though. Classification does not turn on which box generated the SIP INVITE; it turns on the FCC's service definitions and on the actual entity and contract arrangement (again, DA 26-72). The question is whether your company is the one furnishing an end-user voice service that interconnects with the PSTN using telephone numbers: you hold the customer relationship, the service the numbers ride on is yours, and you bill for it. In the full-stack model the answer is usually yes, which is why this scenario carries the clearest obligations. The [SIP trunk](/blog/sip-trunking) provider handles the physical interconnection with the telephone network, but that does not make it the provider of your end users' service. In the context of robocall mitigation and STIR/SHAKEN, the originating provider has specific obligations that we will cover in the next two posts.

Even if you are using a trunk provider that handles STIR/SHAKEN signing and has its own FCC filings, your role as the provider of the end-user service creates regulatory surface area. The trunk provider's compliance does not automatically extend to cover you. You may have independent obligations.

### The gray zone

Real-world arrangements often do not fit neatly into these categories. You might resell a hosted platform for most clients but have a few clients on a PBX you manage with your own trunking. You might use a wholesale provider for most trunking but have a direct trunk with a carrier for a specific use case. You might operate in a co-managed model where the line between your responsibilities and the provider's is defined by a contract that was written by a sales team, not a compliance team.

The gray zone is exactly where you do not want to be when the FCC comes asking questions. And the FCC has been asking more questions in recent years, particularly around robocall mitigation, because the political pressure to address robocalling has driven aggressive enforcement.

## What comes with VSP classification

If you are classified as a Voice Service Provider, a set of obligations generally follows. The specifics depend on the exact nature of your service and the regulatory framework that applies, but the major categories include:

### FCC registration and filings

Voice service providers in the United States are generally required to register with the FCC. This includes filing a Form 499-A (Telecommunications Reporting Worksheet) annually, which is used to determine your contribution obligations to the Universal Service Fund, Telecommunications Relay Services Fund, and other federal programs. The filing is based on your revenue from telecommunications services.

Many voice service providers also hold an Operating Company Number (OCN), a unique identifier used for billing, routing, and regulatory tracking across the telephone network. The OCN is how the rest of the telephone network identifies a company in billing records, Local Exchange Routing Guide (LERG) entries, and regulatory filings, and facilities-based carriers that need LERG entries and direct interconnection generally obtain one. But an OCN is not a universal prerequisite: the FCC's RMD filing guidance ([DA 26-72](https://docs.fcc.gov/public/attachments/DA-26-72A1.txt)) is explicit that a filer supplies an OCN only if it already has one, and does not need to obtain one merely to file. What every filer does need is its own FCC Registration Number (FRN).

If you have not been filing and you should have been, this creates a back-liability problem. The obligation existed whether you knew about it or not, and the FCC can assess contributions retroactively.

### Universal Service Fund contributions

Providers of interstate and international telecommunications services are required to contribute to the Universal Service Fund. The contribution is calculated as a percentage of your interstate and international telecommunications revenues, and the percentage changes quarterly based on FCC calculations. Recent quarters have run between 37 and 39 percent of applicable revenues (the third-quarter 2026 factor is 38.8 percent, a record), and the figure changes every quarter, so check [the FCC's quarterly contribution factor](https://docs.fcc.gov/public/attachments/DA-26-546A1.pdf) notice for the current number.

Note that the contribution is on applicable revenue, not on all revenue. The determination of what portion of your revenue is "interstate and international telecommunications" versus other categories requires analysis that a telecom attorney or compliance consultant can help with.

A common source of confusion: many MSPs see USF surcharges on their own business VoIP bills and assume they are already handling USF. That is a consumer obligation. Your VoIP provider is passing through a portion of its USF contribution to you as a line item on your invoice. Paying USF surcharges as a consumer of voice services does not make you compliant as a provider of voice services. The moment you begin offering interconnected VoIP to clients, your USF obligation shifts from the consumer side to the provider side, and the mechanics are entirely different. You are no longer paying a surcharge passed through by someone else. You are calculating and remitting contributions based on your own telecommunications revenue.

### CPNI compliance

Customer Proprietary Network Information (CPNI) rules govern how you handle information about your customers' telecommunications usage. This includes call records, calling patterns, and other data generated by their use of your service. CPNI rules require you to implement safeguards to protect this information, obtain customer consent before using it for marketing, and file an annual CPNI certification with the FCC.

If you are already handling client data under MSP agreements with appropriate security controls, the CPNI requirements may not require dramatic changes to your operations. But they are specific to telecommunications data and have their own certification requirements that are separate from any security frameworks you already comply with.

### E911 obligations

If you provide voice services that can be used to call 911, you have obligations around Enhanced 911 (E911). This means ensuring that when a user dials 911, the call is routed to the appropriate Public Safety Answering Point (PSAP) and that the caller's location information is delivered with the call. For fixed locations, this means maintaining accurate address information for each endpoint. For nomadic users (employees who take their phone home or to a different office), this means having processes to update location information when users move, a requirement that most remote softphone deployments get wrong.

E911 is one of the areas where getting it wrong has consequences beyond regulatory fines. If someone calls 911 from a VoIP phone and the call goes to the wrong PSAP or arrives without location information, the delay in emergency response can have life-safety implications. This is not a theoretical concern. It has happened, and the FCC takes E911 compliance seriously for that reason. If you deploy or manage multi-line phone systems, Kari's Law and the RAY BAUM'S Act add two more obligations on top of E911 routing: direct 911 dialing with no prefix (with on-site notification), and dispatchable location (floor, suite, room) delivered with the call.

### Robocall mitigation and STIR/SHAKEN

This is the area where FCC enforcement has been most aggressive in recent years, and it is directly relevant to MSPs who originate calls. We are dedicating the next two posts entirely to STIR/SHAKEN and the Robocall Mitigation Database, so we will not go deep here. The short version: if you are a voice service provider, you are required to have a robocall mitigation program regardless of your STIR/SHAKEN implementation status, and to certify both (the mitigation program and your STIR/SHAKEN status) in the FCC's Robocall Mitigation Database under [47 CFR § 64.6305](https://www.ecfr.gov/current/title-47/chapter-I/subchapter-B/part-64/subpart-HH/section-64.6305). And if your filing does not appear in the database, downstream providers are required to refuse your traffic: refusal is mandatory for them, not discretionary.

### State-level obligations

Federal FCC obligations are only part of the picture. Many states have their own telecommunications regulatory requirements, including state-level registration, taxation, and reporting obligations. The specifics vary significantly by state. Some states have minimal requirements for VoIP providers. Others require state-level certification of authority to provide telecommunications services. And the state-by-state variation extends beyond provider obligations to how your clients use the service: [call recording consent laws differ between one-party and all-party consent states](/blog/call-recording-laws-by-state), which matters for any client recording calls across state lines.

If you have clients in multiple states, which most MSPs do, you potentially have obligations in each state where you have customers. State compliance is a separate workstream from federal compliance, and it adds meaningful complexity, particularly for smaller providers who may not have the administrative infrastructure to track and comply with requirements across dozens of jurisdictions.

## "I'm just an MSP" is not a defense

The most common mistake MSPs make in this area is assuming that because they think of themselves as IT services companies, telecommunications regulations do not apply to them. This assumption is understandable but dangerous.

The FCC has been clear that the obligations around voice services apply based on what you do, not what you call yourself. If you furnish end users a voice service that interconnects with the PSTN using telephone numbers, you are providing a voice service in the regulatory sense, and you have the obligations that come with that. The fact that you also manage their firewalls and patch their servers does not create an exemption. If you need to verify the carrier status of numbers you manage or numbers flagged in a compliance inquiry, a [Carrier Lookup](/tools/carrier-lookup) can confirm the current serving carrier and number type.

This is not about the FCC targeting MSPs specifically. It is about the FCC closing gaps in the regulatory framework that robocallers and bad actors have exploited. The broad definition of Voice Service Provider is intentional, designed to ensure that every entity in the call chain has responsibilities for the calls that flow through its systems.

FCC enforcement actions against voice service providers for compliance failures have resulted in penalties exceeding six figures. For a small MSP, a single enforcement action can erase years of profit. And because USF contributions can be assessed retroactively, an MSP that has been operating a voice business for several years without proper filings could face a back-assessment covering every year of non-compliance, landing as a single bill. The financial exposure is not proportional to the size of the provider. It is proportional to the duration and scope of the non-compliance.

## The distinction between what your upstream carrier handles and what falls on you

One of the most common sources of confusion is the assumption that if your SIP trunk provider is compliant, you are compliant by extension. This is not generally how it works.

Your trunk provider has its own obligations. It files its own FCC reports, makes its own USF contributions, and manages its own STIR/SHAKEN implementation. Those filings cover the trunk provider's operations. They do not automatically extend to cover yours.

Think of it this way. Your trunk provider is responsible for the calls from the perspective of a transit or terminating carrier. You are responsible for the calls from the perspective of an originating provider. These are different roles in the call chain, and each role has its own set of obligations.

That said, the specifics depend heavily on the contractual arrangement between you and the trunk provider. Some trunk providers explicitly take on certain compliance responsibilities on behalf of their customers. Others explicitly disclaim those responsibilities. The contract matters, and so does the actual operational reality.

If your trunk provider's agreement says they handle STIR/SHAKEN signing for calls originating from your trunks, and they actually do it correctly, that may satisfy your STIR/SHAKEN implementation requirement. But it may not satisfy your requirement to file in the Robocall Mitigation Database, which is a separate obligation. The layers are distinct, and each one needs to be addressed.

## How to figure out where you stand

If you have been operating a voice business without thinking about regulatory classification, the right move is not to panic. It is to assess your situation methodically.

**Map your involvement.** For each client, trace the call path. Where does the SIP signaling originate? Who operates the PBX? Who holds the trunk? Who selected the caller ID? Who bills the client for voice service? The answers to these questions determine your role in the call chain.

**Read your agreements.** Look at your wholesale provider agreements, your trunk provider agreements, and your client-facing service agreements. Who is identified as the provider of record? What compliance obligations are allocated to each party? Are the allocations explicit or ambiguous?

**Identify the gaps.** Compare your operational reality against the obligations described above. Are you filing with the FCC? Are you making USF contributions? Do you have CPNI processes? Is your E911 provisioning current? Have you filed in the Robocall Mitigation Database?

**Talk to a telecom attorney.** This is the step that most MSPs skip because they do not have an existing relationship with a telecom attorney, or because they assume the cost is not justified. Both assumptions are usually wrong. Have counsel classify each legal entity and each service model you operate; the analysis can come out differently for different entities and offerings under the same roof. Telecom attorneys who work with small providers and resellers are not rare, and the cost of a consultation to assess your situation is trivial compared to the cost of an FCC enforcement action or the operational disruption of having your traffic blocked because your Robocall Mitigation Database filing lapsed.

## Why this conversation should happen before you launch, not after

If you are reading this series because you are evaluating whether to add voice to your MSP, you have an advantage: you can build compliance into your plan from the beginning. It is dramatically easier and cheaper to set up the right structure from the start than to retrofit compliance after you are already operating.

Before you sign a wholesale agreement, before you provision your first trunk, before you make your first sale, sit down with a telecom attorney and walk through your planned service model. Tell them exactly what you intend to do: what platform you plan to use, who will provide trunking, how you will bill clients, what brand name will appear on invoices. Let them tell you what obligations attach to that structure and what filings you need to make.

If the answer is "your wholesale provider handles everything and you have no independent obligations," that is great. Get it in writing. If the answer is "you need to file with the FCC, register in the Robocall Mitigation Database, and set up CPNI procedures," that is also fine, but you need to do those things before you start, not three years into operating when someone notices you have not filed.

The worst position is the one where you have been operating for years, you have hundreds of clients on voice, and you discover that you should have been filing all along. The obligations do not disappear because you were unaware of them. Back-filing is possible, but it is more complex and more expensive than getting it right from the start.

## The practical reality

Let's be honest about how this plays out in practice. The vast majority of MSPs reselling white-label hosted VoIP under a wholesale provider's umbrella have limited independent regulatory obligations, because the wholesale provider is structured to be the provider of record. If you are in that category and your wholesale agreement clearly allocates compliance responsibilities to the provider, your exposure is relatively contained.

But "relatively contained" is not the same as "zero," and the landscape shifts as you move along the spectrum. If you are in a co-managed arrangement with your own trunking, or if you are operating full stack, the obligations are real and the consequences of non-compliance are material.

The next two posts cover the two areas where FCC enforcement has been most active and where the consequences of non-compliance are most immediate: STIR/SHAKEN call authentication and the Robocall Mitigation Database. These are not theoretical compliance exercises. They directly affect whether your clients' calls get completed or get blocked. Understanding them is essential regardless of where you sit on the service model spectrum.

---

*Next up: [STIR/SHAKEN: Why Your Clients' Calls Are Getting Flagged](/blog/msp-stir-shaken), the call authentication framework that determines whether your outbound calls show up as legitimate business or get slapped with a spam label.*

---

### Part 18: STIR/SHAKEN: Why Your Clients' Calls Are Getting Flagged

URL: https://voiptest.com/blog/msp-stir-shaken
Published: 2026-03-27
Tags: msp, stir-shaken, caller-id, attestation, robocall, compliance

*The MSP's Guide to VoIP: Part 18 of 20*

> **Disclaimer:** This post is educational content about the STIR/SHAKEN call authentication framework and its implications for voice service providers. It is not legal advice. Regulations change, interpretations vary, and your specific situation may differ from the general scenarios described here. Consult with a telecom attorney to determine how these regulations apply to your business.

Your client calls you on a Tuesday morning. Their sales team has noticed that prospects are not answering the phone. When prospects do answer, some of them mention that the call showed up as "Spam Likely" on their phone. The client's outbound calling numbers are legitimate, their business is legitimate, and they are not making robocalls. But the phone network does not know that, because the calls are not being properly authenticated.

This is a STIR/SHAKEN problem, and it is one of the most common voice issues MSPs encounter today that has nothing to do with network quality, [codec configuration](/blog/choppy-robotic-audio), or [SIP signaling errors](/blog/sip-response-codes). It is an identity and trust problem, and understanding how it works is essential for anyone managing voice services.

## The problem STIR/SHAKEN was created to solve

To understand STIR/SHAKEN, you need to understand the problem it was designed to address. The traditional telephone network had a fundamental trust weakness: caller ID was asserted by the originating party and accepted at face value by the rest of the network. There was no mechanism to verify that the entity placing the call was authorized to use the displayed caller ID number.

This was fine when the telephone network was a closed system operated by a handful of carriers with physical interconnection points. It became a catastrophic vulnerability when VoIP made it trivially cheap to originate millions of calls with arbitrary caller ID values. Robocallers exploited this by spoofing caller IDs, displaying numbers they did not own to make their calls appear local, appear to come from legitimate businesses, or appear to come from government agencies.

The scale of the problem became staggering. At peak, American consumers were receiving an estimated 4 to 5 billion robocalls per month. The calls were not just annoying. They were vehicles for fraud. Spoofed caller IDs made it nearly impossible for consumers to distinguish legitimate calls from scam calls, and the erosion of trust in the telephone system became a policy priority.

The TRACED Act of 2019 directed the FCC to mandate implementation of a call authentication framework for providers of interconnected VoIP, meaning any VoIP service that connects to the PSTN. That framework is STIR/SHAKEN. It has not eliminated robocalls (the reasons [caller ID still lies in 2026](/blog/stir-shaken-reality-2026) are worth understanding on their own), but it has fundamentally changed how carriers evaluate every call, including your clients' legitimate ones.

## What STIR/SHAKEN actually is

STIR/SHAKEN is a pair of related standards. STIR (Secure Telephone Identity Revisited) defines the mechanism for creating and verifying digital signatures on calls. SHAKEN (Signature-based Handling of Asserted information using toKENs) defines how STIR is implemented in telephone networks using SIP signaling.

The core concept is straightforward. When a call is originated, the originating service provider creates a digital signature (a cryptographic token) that attests to the relationship between the calling party and the caller ID number being displayed. This token is attached to the [SIP INVITE](/blog/first-call-flow-invite-to-bye) as an Identity header. As the call traverses the network, downstream carriers can verify the signature using the originating provider's public certificate, confirming that the call was signed by a legitimate provider and that the caller ID has not been tampered with in transit.

It works on the same basic principle as HTTPS certificates on the web. A certificate authority issues a digital certificate to the voice service provider. The provider uses that certificate to sign calls. The receiving carrier verifies the signature against the certificate authority's trust chain. If the signature is valid, the receiving carrier knows that a legitimate, identified provider originated the call and attested to the caller ID.

## The three attestation levels

Not all STIR/SHAKEN signatures are equal. The originating provider assigns one of three attestation levels to each call, and the level chosen has real-world consequences for how the call is treated downstream.

### Full attestation (A)

Full attestation means the originating provider has verified that the calling party is authorized to use the specific phone number displayed as the caller ID. The provider knows who the customer is, the customer has an established relationship with the provider, and the number being displayed belongs to that customer or is assigned to them by the provider.

This is the gold standard. Calls with full attestation are the most trusted by downstream carriers and analytics engines. They are the least likely to be flagged as spam or blocked. For your clients' outbound business calls, full attestation is what you want.

Full attestation is achievable when the numbers being used as caller ID are assigned to the customer by the same trunk provider that is signing the calls. If a client has ten DIDs assigned to their trunk, and they place calls displaying one of those ten DIDs, the trunk provider can verify that the number belongs to the customer and sign with full attestation.

### Partial attestation (B)

Partial attestation means the originating provider has verified the customer's identity and has an established relationship with them, but cannot confirm that the customer is authorized to use the specific number displayed. The provider knows who is making the call, but the number shown might not be one the provider assigned.

This commonly occurs when a customer sends a caller ID number that is valid and belongs to them but is assigned through a different provider. For example, a business might have phone numbers from a previous carrier that they are displaying through a new trunk provider. The new provider can verify the customer's identity but cannot verify ownership of numbers they did not assign.

Partial attestation is a step down from full. Calls with partial attestation are not automatically flagged, but they receive less trust from analytics engines than fully attested calls. In an environment where carriers are aggressively filtering, partial attestation calls have a higher probability of being flagged or receiving reduced caller ID treatment.

### Gateway attestation (C)

Gateway attestation means the originating provider can identify the source of the call (it came from a specific gateway or interconnection point) but cannot verify the caller's identity or their authorization to use the displayed number. This is the lowest attestation level.

Gateway attestation is common for calls entering a provider's network from international gateways, from legacy TDM interconnections, or from sources where the provider has limited visibility into the originating party. It is essentially a statement of "this call came from a known point, but we cannot vouch for anything else about it."

Calls with gateway attestation are the most likely to be flagged by analytics engines and blocked by carrier spam filters. If your clients' calls are consistently receiving gateway attestation when they should be getting full or partial, that is a problem that needs to be addressed with the trunk provider.

## How attestation affects call completion

The practical impact of attestation is significant and measurable. Carriers and mobile handset manufacturers use attestation level as one of several inputs to their call scoring algorithms. These algorithms determine what the recipient sees when the phone rings: the caller's name and number, a "Verified" badge, a "Spam Likely" label, or nothing at all because the call was silently blocked.

The downstream effects cascade. When calls are flagged as spam, answer rates drop. Industry data suggests that calls flagged as spam are answered at rates 50 to 80 percent lower than verified calls. For a business that depends on outbound calling (sales teams, appointment reminders, follow-up calls), this directly affects revenue and operations.

When calls are blocked entirely, the caller may not even know. Some carriers silently block suspected spam calls rather than routing them to voicemail. The call appears to complete normally from the originator's perspective (they might hear ringback tone or get voicemail), but the recipient's phone never rings. This is particularly insidious because the business believes they are reaching people when they are not.

The attestation level is not the only factor in call scoring. Analytics companies like TNS (Transaction Network Services), Hiya, and First Orion also consider calling patterns, call volume, complaint history, number registration status, and other signals. But attestation is a foundational input, and getting it wrong undermines everything else.

## Where signing happens in the network

Understanding where STIR/SHAKEN signing occurs helps you figure out who is responsible for your clients' attestation level and where to go when there is a problem.

STIR/SHAKEN signing happens at the originating service provider's network edge, typically at a Session Border Controller (SBC) or equivalent element that processes outbound calls before they leave the provider's network. The provider's SBC has access to the provider's STIR/SHAKEN certificate and the private key used for signing. When an outbound call passes through the SBC, the SBC evaluates the call, determines the appropriate attestation level, creates the cryptographic token, and attaches it to the SIP INVITE as an Identity header.

For an MSP in a white-label resale arrangement, signing typically happens at the wholesale provider's infrastructure. Your client's PBX (or the hosted platform) sends the call to the wholesale provider's SBC, and the SBC signs it. The attestation level depends on whether the wholesale provider recognizes the caller ID number as belonging to the customer.

For an MSP with their own trunking, signing typically happens at the trunk provider's SBC. Your PBX sends the INVITE through the [SIP trunk](/blog/sip-trunking), and the trunk provider's SBC signs it before routing it toward the destination. Again, the attestation level depends on the trunk provider's ability to verify the caller ID.

In either case, the entity doing the signing needs accurate information about which numbers belong to which customer. If your client's numbers are not properly registered in the signing provider's system, the provider cannot verify ownership and will default to partial or gateway attestation.

One thing outsourcing does not do is move the obligation. Under the FCC's third-party authentication rules (see the FCC's Robocall Mitigation Database FAQ, DA 26-72), a provider that has a STIR/SHAKEN obligation and hires someone else to perform the signing is still the one making the attestation decision, and the calls must be signed with that provider's own certificate, not the contractor's. Whose SBC executes the cryptography is an operational detail; whose certificate and whose judgment stand behind the attestation is the regulatory question.

### The certificate authority chain

STIR/SHAKEN certificates are issued by certificate authorities approved by the STI Policy Administrator (STI-PA), which operates under the oversight of the industry-led STI Governance Authority (STI-GA) in the United States. To obtain a certificate, a voice service provider must qualify for a Service Provider Code (SPC) token from the STI-PA and maintain that standing; the certificate is issued against the SPC token.

This is relevant to MSPs because obtaining your own STIR/SHAKEN certificate requires that you be recognized as a voice service provider, which circles back to the [regulatory classification](/blog/msp-regulatory-landscape) discussion from the previous post. Be careful with the causality here: signing a contract with a wholesale provider does not decide whether you are yourself a provider. That is decided by applying the FCC's definitions to how the service actually operates: who the customer's provider is, who controls the numbers, who originates the traffic. If the wholesale provider is the voice service provider under those definitions, its certificate properly covers the calls. If *you* are the provider, you need your own SPC token and certificate even if a contractor runs the signing infrastructure for you (FCC DA 26-72), and what your SPC token, certificate, and Robocall Mitigation Database filing represent must match your actual implementation, complete or partial, not the implementation you have delegated on paper.

## What happens when calls are not properly attested

When your clients' calls leave the network without STIR/SHAKEN signing, or with a lower attestation level than they should have, the consequences show up in several ways.

**Spam labels.** The recipient's phone displays "Spam Likely," "Scam Likely," "Potential Spam," or similar labels alongside or instead of the caller ID. The specific label varies by carrier and handset, but the effect is the same: the recipient does not trust the call.

**Reduced answer rates.** Even without an explicit spam label, calls without verification badges are answered less frequently than verified calls. As consumers become conditioned to screening calls, the absence of verification is itself a negative signal.

**Outright blocking.** Some carriers and call-blocking apps block unverified calls or calls with poor attestation without delivering them to the recipient. The call may go to voicemail or may receive no treatment at all.

**Client frustration.** Your client does not understand or care about STIR/SHAKEN. They know that their calls used to get answered and now they don't. They know their caller ID says "Spam Likely" when their customer looks at their phone. And they expect you to fix it, because you are managing their phone system.

## The MSP's responsibilities depending on role in the call chain

Where your obligations sit depends on the service model you are operating under, as discussed in the [previous post](/blog/msp-regulatory-landscape) and in [Post 2](/blog/msp-voice-service-models).

### Referral model

If you referred the client to a hosted VoIP provider, STIR/SHAKEN is the provider's responsibility. You might still get the call when the client complains about spam labels, and you should understand enough to explain the issue and point the client toward their provider. But the implementation is not on you.

### White-label resale

In a resale model, STIR/SHAKEN signing is typically performed by your wholesale provider. Whether that arrangement also satisfies the regulatory obligation depends on who the voice service provider is under the FCC's definitions; the contract does not settle that question, the service model does. If the analysis puts the obligation on you, the wholesale provider is acting as your signing contractor: you still own the attestation decisions and the calls must carry your certificate, not theirs (FCC DA 26-72). Assuming the wholesaler is the provider of record, your responsibilities are:

- Ensuring that all of your clients' phone numbers are properly registered in the wholesale provider's system so that the provider can verify ownership and sign with full attestation.
- Verifying that your wholesale provider is actually implementing STIR/SHAKEN correctly and signing calls at the appropriate attestation level.
- Being the first point of contact when clients report spam labeling issues and knowing how to escalate to the wholesale provider with the right information.

The most common resale-side issue is number registration gaps. A client gets a new DID, it is provisioned on the phone system but never registered with the trunk provider's STIR/SHAKEN system, and calls from that number go out with partial or no attestation. This is an operational process issue, not a technology issue, and it is entirely preventable with proper provisioning procedures.

### Co-managed and full stack

If you are originating interconnected VoIP calls on your own trunking, your responsibilities expand. If you are the originating voice service provider under the FCC's definitions, the STIR/SHAKEN obligation is yours: you need your own certificate, you make the attestation decisions, and outsourcing the signing operation to your trunk provider does not change either of those facts: the contractor signs with your certificate, at the attestation levels you determine (FCC DA 26-72). You need to have all client numbers registered with the signing entity. And you need to have filed in the Robocall Mitigation Database with a representation that matches your actual complete or partial implementation, which we will cover in the [next post](/blog/msp-robocall-mitigation-database).

If you have your own SBC that is capable of STIR/SHAKEN signing and you have obtained your own certificate, you have direct control over the signing process. This gives you more control but also more responsibility, since you need to manage certificate renewal, ensure your signing infrastructure is functioning correctly, and keep your number inventory current.

## Why this matters to your clients' daily business

Most of your clients have never heard of STIR/SHAKEN. They do not know what attestation levels are, they do not know what the Identity header in a SIP message contains, and they do not care. What they know is whether their phone calls get answered.

For businesses that depend on outbound calling, attestation problems are business problems. A medical office that calls patients to confirm appointments and gets flagged as spam is going to have higher no-show rates. A sales team that makes 200 outbound calls per day and gets flagged is going to see their connect rates crater. A law firm that calls clients from a number labeled "Spam Likely" is going to have a credibility problem.

These clients do not need to understand the technical details. They need their MSP to understand the technical details and make sure the right things are configured correctly so that their calls are properly authenticated and their phone numbers have good reputations.

This is also why the [caller ID configuration](/blog/caller-id-problems) work matters more than ever. Making sure the right number appears on outbound calls is not just a cosmetic issue. It determines which number gets attested, which number's reputation is affected by the calling patterns, and which number gets flagged if something goes wrong. Sending calls with the wrong caller ID is not just confusing to the recipient. It can result in attestation failures that damage the reputation of a number the client does not even intend to be using.

## Practical steps for MSPs

Regardless of your service model, here are the things you should be doing:

**Verify attestation levels.** Ask your trunk provider or wholesale provider what attestation level your clients' calls are receiving. Some providers offer dashboards or reports that show attestation statistics. If they do not, ask them to check specific numbers. You want full attestation on all outbound calls where the caller ID number is assigned to the customer through the same provider chain.

**Audit number registration.** Go through your clients' phone numbers and verify that every number is properly registered in the signing provider's system. Pay particular attention to numbers that were ported in from other providers, numbers that were added after the initial provisioning, and toll-free numbers (which have their own attestation considerations).

**Monitor for spam labels.** Periodically check your clients' main outbound numbers against the major spam databases and carrier lookup tools. Services like Free Caller Registry allow you to check how numbers are being categorized. Watch for client complaints about recipients mentioning spam labels. If you are doing [proactive monitoring](/blog/msp-proactive-monitoring), consider adding caller reputation checks to your regular review cycle.

**Document your STIR/SHAKEN implementation.** Whether you rely on a wholesale provider or manage your own signing, document how STIR/SHAKEN is handled for your voice services. This documentation will be important for your Robocall Mitigation Database filing, which we cover next.

**Build it into provisioning.** When you onboard a new client or add numbers to an existing client's service, make STIR/SHAKEN registration part of your provisioning checklist. The time to ensure proper attestation is during provisioning, not after the client calls to complain that their sales team is being flagged as spam.

---

*Next up: [The Robocall Mitigation Database and FCC Filing Requirements](/blog/msp-robocall-mitigation-database), the federal database that determines whether your traffic gets carried or blocked and what you need to do to stay in it.*

---

### Part 19: The Robocall Mitigation Database and FCC Filing Requirements

URL: https://voiptest.com/blog/msp-robocall-mitigation-database
Published: 2026-03-28
Tags: msp, rmd, fcc-filing, robocall-mitigation, compliance, traceback

*The MSP's Guide to VoIP: Part 19 of 20*

> **Disclaimer:** This post is educational content about the FCC's Robocall Mitigation Database and associated filing requirements. It is not legal advice. Regulations change, interpretations vary, and your specific situation may differ from the general scenarios described here. Consult with a telecom attorney to determine how these regulations apply to your business.

If the [previous post](/blog/msp-stir-shaken) on STIR/SHAKEN was about how calls get authenticated, this post is about the regulatory infrastructure that sits behind that authentication, specifically the FCC's Robocall Mitigation Database (RMD) and the filing requirements that determine whether your voice traffic gets carried by downstream carriers or gets blocked at the interconnection point.

This is one of those topics that sounds like it only matters to large carriers, and then you discover that the obligations extend much further down the food chain than you expected. If you are providing interconnected VoIP (any VoIP service that connects to the PSTN) and originating voice calls in any capacity, you need to understand how the RMD works and whether you have a filing obligation.

## What the Robocall Mitigation Database is

The Robocall Mitigation Database is a publicly accessible database maintained by the FCC that lists voice service providers and their certifications regarding STIR/SHAKEN implementation and robocall mitigation. It was established as part of the FCC's implementation of the TRACED Act, and its purpose is both regulatory and operational.

The regulatory purpose is to create accountability. By requiring voice service providers to publicly certify their compliance with STIR/SHAKEN mandates or describe their robocall mitigation programs, the FCC creates a record that can be used for enforcement. If a provider is identified as a source of illegal robocall traffic, the FCC can check whether they filed, what they claimed in their filing, and whether their actual practices match their claims.

The operational purpose is more immediately consequential for your day-to-day business. Under FCC rules, intermediate and terminating carriers are generally required to block voice traffic from voice service providers that do not have an active filing in the RMD. This is not a theoretical enforcement mechanism. It is an automated one. If your filing lapses or you never filed at all, carriers downstream in the call path may be required to block your traffic. The result is that your clients' calls simply do not complete.

The database is publicly searchable at the FCC's website. Anyone can look up a provider and see whether they have an active filing, what type of filing they made, and when it was last updated. This transparency is intentional, allowing carriers to verify filing status before accepting traffic, and it allows end users and other stakeholders to check their provider's compliance.

## Who needs to file

The filing requirement applies broadly to voice service providers, and the definition of voice service provider for RMD purposes has been discussed in [Post 17](/blog/msp-regulatory-landscape). The general rule is that if you provide interconnected VoIP and originate voice traffic that enters the PSTN, you should evaluate whether you have a filing obligation.

The FCC has identified several categories of entities that are generally expected to file:

**Facilities-based carriers** that operate their own switching and transmission infrastructure. These are the traditional phone companies and VoIP carriers that most people think of when they hear "voice service provider."

**Non-facilities-based providers** that originate voice traffic through other carriers' infrastructure. This includes resellers, over-the-top VoIP providers, and entities that use SIP trunking to originate calls but do not operate their own network infrastructure.

**Intermediate providers** that receive and forward voice traffic between other providers. These are the transit carriers and tandem switches in the middle of the call path.

**Gateway providers** that receive calls from outside the United States and introduce them into the domestic telephone network.

The category that catches MSPs off guard is the second one. If you are originating calls through a [SIP trunk](/blog/sip-trunking), even if you do not own the trunk infrastructure and even if you think of yourself as a small IT company, you may fall into the category of a non-facilities-based provider that has a filing obligation. The determination depends on the specific facts of your operation and the contractual structure with your trunk provider.

Be careful with the common assumption that an upstream provider's filing "covers" the companies downstream of it. The FCC's filing guidance (DA 26-72) is explicit that every entity that independently meets the definition of a voice service provider (and it explicitly includes VoIP resellers here) must make its own RMD filing; an upstream provider's filing is not a blanket substitute. So the real question is not "does my wholesaler's filing cover me" but "do I meet the definition at all." If you are purely a sales channel and the wholesale provider is the entity furnishing the end-user voice service (it is the provider of record, holds the numbers, provides the service under its own authority), then you may not meet the definition and have nothing to file. If you do meet the definition, you file your own certification, regardless of what your upstream has filed.

Other MSPs have a less clear picture. If you operate your own PBX, contract directly with a trunk provider, and furnish the resulting voice service to your clients, you are likely the voice service provider for RMD purposes, even though the trunk provider handles the actual PSTN interconnection. The trunk provider's filing covers the trunk provider. It does not cover you.

This is the kind of determination that benefits from the telecom attorney consultation we recommended in the [previous post](/blog/msp-regulatory-landscape). The cost of getting a definitive answer is small. The cost of getting it wrong is not.

## What a filing contains

An RMD filing is not a complex legal document. It is a structured certification that contains several key elements:

**Provider identity.** The name of the voice service provider, contact information, the entity's own FCC Registration Number (an FRN is required: you register for one if you do not already have it, and you file under your own FRN, not your upstream's), and an Operating Company Number only if the filer already possesses one. Per the FCC's guidance (DA 26-72), you do not need to obtain an OCN merely to file. Where present, the OCN ties your filing to your identity in the broader telephone network's billing and routing systems. This is the basic "who are you" information.

**STIR/SHAKEN implementation status.** The provider certifies one of the following:

- They have fully implemented STIR/SHAKEN and are signing outbound calls with the appropriate attestation levels. This is the preferred certification for providers that are subject to the STIR/SHAKEN mandate.

- They have partially implemented STIR/SHAKEN (for example, they sign some but not all calls, or they sign calls on some but not all parts of their network). In this case, they describe what they have implemented and what remains.

- They have not implemented STIR/SHAKEN but have implemented a robocall mitigation program. This option is available for smaller providers and others that qualify for an exemption from the STIR/SHAKEN mandate. In this case, they must describe their robocall mitigation program.

**Robocall mitigation program description.** If the provider has not fully implemented STIR/SHAKEN, they must describe the specific practices they use to prevent illegal robocall traffic from originating on their network. This includes call analytics, traffic monitoring, customer vetting procedures, and other measures.

**Commitment to cooperate with traceback.** The provider certifies that they will cooperate with traceback requests from the Industry Traceback Group (ITG) or other authorized entities. Traceback is the process of tracing the origin of illegal robocalls back through the network to the originating provider. When the ITG identifies suspicious traffic, they send traceback requests to providers in the call chain, and each provider is expected to respond with information about where the traffic came from.

This commitment to cooperate is not optional or symbolic. The ITG conducts thousands of tracebacks, and providers that do not respond or respond slowly are flagged. Repeated failure to cooperate with tracebacks can lead to FCC enforcement action and can be cited by downstream carriers as a reason to block traffic.

**Certifying official.** A named individual at the provider who certifies under penalty of perjury that the information in the filing is accurate. This is not a rubber-stamp exercise. The certifying official is personally attesting to the accuracy of the filing, and making a false certification has legal consequences.

## Filing cadence and what happens when a filing lapses

RMD filings are not one-time events. Under the FCC's current rules (DA 26-72), existing filers recertify annually on or before March 1, and must update their filing within 10 business days whenever the information in it changes: a new trunk provider, a change to your STIR/SHAKEN implementation, a change to your robocall mitigation program.

The annual recertification requirement means that even if nothing has changed about your operations, you need to actively renew your filing. A filing that was accurate and complete on the day it was submitted becomes a lapsed filing if it is not recertified by the deadline. And a lapsed filing, from the perspective of downstream carriers checking the database, looks the same as no filing at all.

When a filing lapses, the consequences can be swift. Carriers that check the RMD before accepting traffic (and they are required to under FCC rules) may begin blocking traffic from a provider with a lapsed filing. The blocking is not punitive in intent; the carrier is complying with its own obligation to not accept traffic from non-compliant providers. But the effect on the provider whose filing lapsed is the same as if they were deliberately blocked: calls stop completing.

The timeline from filing lapse to traffic disruption varies. Some carriers check filing status in real time or near real time. Others check on a periodic basis. But the trend has been toward more automated and more frequent checking, which means the window between a filing lapse and traffic disruption is shrinking.

Re-filing after a lapse is possible and the database will update relatively quickly once a new filing is submitted. But the disruption during the lapse period can be significant, particularly if your client base depends on outbound calling. Getting ahead of the renewal deadline is dramatically better than scrambling to re-file after your traffic has already been blocked.

## Downstream consequences: what blocked traffic looks like

When carriers block your traffic due to a missing or lapsed RMD filing, the experience for your clients and their call recipients depends on how the blocking is implemented.

**Hard blocking** means the call is rejected at the network level. The originating provider (your trunk provider or your SBC) receives a [SIP response](/blog/sip-response-codes) indicating that the call cannot be completed. Depending on the specific response code used, your PBX may present this to the caller as a busy signal, a "call cannot be completed" message, or a generic failure. The caller knows the call did not go through.

**Soft blocking** means the call is accepted by the intermediate or terminating carrier but not delivered to the recipient. The call might be sent to a generic voicemail, dropped silently, or answered by an announcement. The caller may believe the call was delivered normally when it was not. This is harder to detect and harder to troubleshoot.

**Selective blocking** means that some carriers block your traffic while others still carry it. This results in a pattern where calls to some destinations work and calls to others do not. Your clients report that they can call some people but not others, and the pattern correlates with the terminating carrier rather than the geographic destination.

From a troubleshooting perspective, RMD-related blocking can look like a trunk issue, a routing issue, or a seemingly random failure pattern. If you are seeing widespread call completion failures that do not correlate with your network conditions or your trunk provider's status, checking the RMD filing status should be on your diagnostic list. This is especially true if the failures appeared suddenly without any changes to your infrastructure.

## How to check where you stand in a resale arrangement

If you are in a resale arrangement and you believe you have no independent filing obligation, verify that assumption rather than relying on it. Keep the frame from above in mind: an upstream filing never substitutes for a filing you owe (DA 26-72); what you are actually verifying is who furnishes the end-user voice service, and therefore whether you meet the definition yourself.

**Check the RMD directly.** Go to the FCC's Robocall Mitigation Database and search for your upstream provider. Verify that they have an active filing and that it is current. Note the date of their last filing update and set yourself a reminder to check again before their renewal is due.

**Read the filing.** RMD filings are publicly accessible. Read your provider's filing and check whether it describes an arrangement that covers traffic originated by their resellers and downstream customers. Some providers explicitly address this in their filing. Others do not, which creates ambiguity.

**Ask the provider directly.** Contact your wholesale provider or trunk provider and ask explicitly: "Under our arrangement, who is the provider of record furnishing voice service to the end users: you or me?" Get the answer in writing. If the answer is that they are, ask them to point you to the specific language in the reseller agreement that supports this. If the answer is that you are, or if they are not sure, you likely meet the definition and have your own filing to make.

**Review your agreement.** Your wholesale or trunk provider agreement should address regulatory compliance responsibilities. Look for provisions that allocate RMD filing obligations. If the agreement is silent on this topic, that is a gap that needs to be addressed, either through an amendment to the agreement or through your own independent filing.

**When in doubt, file.** In ambiguous situations, some providers and their attorneys recommend filing in the RMD independently, and the FCC's own guidance tilts the same direction: if you independently meet the definition, filing is mandatory, and an upstream filing does not substitute (DA 26-72). Having your own active filing eliminates the ambiguity and ensures that if there is ever a dispute about who the provider is, your traffic is not caught in the middle. Filing is not difficult, and it is currently free; the FCC has adopted a $100 recertification fee for the future but states it will not take effect until separately announced. The protection an active filing provides against traffic disruption may justify it even if it turns out you did not strictly need one.

## The traceback process in practice

Traceback is the mechanism by which illegal robocall traffic is traced from the terminating carrier back through the network to the originating provider. The Industry Traceback Group, operating under authority delegated by the FCC, conducts these traces.

A traceback starts when a carrier, government agency, or analytics company identifies a robocall campaign. They provide call detail records (CDRs) to the ITG, which then sends requests to the carriers in the call path, working backward from the terminating carrier toward the originating provider. Each carrier in the chain is asked to identify where the traffic came from, specifically which upstream provider delivered it.

If the traceback reaches you, meaning you are identified as the originating provider or an intermediate provider for the traffic in question, you will receive a traceback request. The request will contain call detail information and will ask you to identify the source of the traffic. You are expected to respond promptly (typically within 24 hours for urgent requests) with the information requested.

For an MSP operating a voice business with legitimate business clients, a traceback request might seem alarming, but it is not necessarily a sign of trouble. Tracebacks can occur because a number assigned to one of your clients was previously used by a robocaller (number recycling), because a client's system was compromised and used to originate fraudulent calls, or because a downstream analytics engine incorrectly flagged legitimate traffic as suspicious.

The important thing is to respond. Cooperating with tracebacks is part of your RMD filing commitment, and failure to cooperate is taken seriously. If you receive a traceback request and you can demonstrate that the traffic was legitimate, or that you have taken action to address the source of illegitimate traffic, that is generally the end of it. If you ignore the request or refuse to cooperate, that creates a much more serious problem.

Having good records matters here. If you can quickly look up a phone number, identify which client it is assigned to, and pull call records for the time period in question, you can respond to a traceback efficiently. A [Carrier Lookup](/tools/carrier-lookup) can help you verify the current carrier assignment and number status when investigating a flagged number. If your records are disorganized or incomplete, a traceback response becomes a fire drill.

## Practical enforcement reality

The FCC has been increasingly active in enforcement around robocall mitigation. They have issued cease and desist orders to providers identified as sources of robocall traffic, ordered downstream carriers to block traffic from specific providers, and imposed fines in egregious cases.

The enforcement landscape has also involved the FCC ordering intermediate carriers to stop carrying traffic from providers that have been identified as bad actors, even when those intermediate carriers were not themselves engaged in any wrongdoing. This cascading enforcement puts pressure on the entire chain, because carriers know that accepting traffic from non-compliant providers creates risk for their own operations.

For MSPs, the practical enforcement risk depends on scale and behavior. A small MSP with a few hundred seats of legitimate business VoIP is not in the same risk category as a wholesale carrier processing millions of calls per day. But the blocking mechanism does not discriminate based on the size of the provider. If your filing lapses, your traffic can be blocked regardless of whether you are originating ten calls per day or ten million. The automated nature of the compliance checking means that small providers face the same filing obligations as large ones.

The most likely enforcement scenario for an MSP is not an FCC investigation or a fine. It is the quiet, operational consequence of a missing or lapsed filing: traffic that stops completing, clients who cannot reach their customers, and a scramble to figure out why. By the time you trace the problem to an RMD filing issue, your clients have already experienced the disruption.

## What this means for your operations

If you have determined (based on the analysis in [Post 17](/blog/msp-regulatory-landscape)) that you have an independent RMD filing obligation, here is what that means operationally:

**Initial filing.** Prepare and submit your RMD filing through the FCC's online system. This includes registering for FCC credentials if you do not already have them, completing the filing form, and having a certifying official submit it. The process is not complex, but it requires accurate information about your STIR/SHAKEN implementation or robocall mitigation program.

**Annual recertification.** Set a calendar reminder well in advance of the March 1 annual recertification deadline (DA 26-72). Recertify before it passes. Do not wait for the FCC to remind you. They may not, and a reminder that arrives after the filing has lapsed is too late to prevent traffic disruption.

**Changes.** If you change your STIR/SHAKEN implementation, your trunk providers, or your robocall mitigation practices, update your filing within 10 business days of the change. The filing is supposed to accurately represent your current practices, not your practices as of the date you originally filed.

**Traceback readiness.** Maintain call records in a format that allows you to respond to traceback requests quickly. Know who your clients are, what numbers are assigned to them, and how to pull call records for a specific number and time period. Designate someone on your team as the point of contact for traceback requests so that they do not get lost in a general support queue.

**Monitoring.** Periodically check the RMD to confirm your filing is active. Check your upstream providers' filings as well. If you rely on multiple trunk providers, check each one. Set alerts for renewal dates across all providers in your chain.

The administrative overhead of maintaining an RMD filing is not large. The initial filing takes a few hours, the annual recertification takes less, and the ongoing maintenance is primarily about keeping records and staying aware of deadlines. Compared to the operational disruption that a filing lapse can cause, it is a small investment.

---

*Next up: [Keeping Your Clients' Calling Reputation Clean](/blog/msp-caller-reputation), covering the ongoing work of monitoring, maintaining, and defending your clients' phone number reputation in a world where analytics engines decide who gets flagged as spam.*

---

### Part 20: Keeping Your Clients' Calling Reputation Clean

URL: https://voiptest.com/blog/msp-caller-reputation
Published: 2026-03-28
Tags: msp, caller-reputation, spam-labels, tcpa, number-registration, compliance

*The MSP's Guide to VoIP: Part 20 of 20*

> **Disclaimer:** This post is educational content about caller reputation management and related compliance topics including the TCPA. It is not legal advice. Regulations change, interpretations vary, and your specific situation may differ from the general scenarios described here. Consult with a telecom attorney to determine how these regulations apply to your business.

The previous three posts covered the regulatory framework: [what makes you a voice service provider](/blog/msp-regulatory-landscape), [how STIR/SHAKEN authenticates calls](/blog/msp-stir-shaken), and [what the Robocall Mitigation Database requires](/blog/msp-robocall-mitigation-database). That framework exists to combat robocalling and caller ID spoofing at a systemic level. This post is about the practical, ongoing work that happens after the framework is in place: the day-to-day reality of keeping your clients' phone numbers in good standing so their calls get answered instead of flagged, blocked, or ignored.

This is not a configure-once-and-forget task. Caller reputation is a living thing. It changes based on calling patterns, complaint activity, number history, registration status, and the constantly evolving algorithms that carriers and analytics companies use to score calls. An MSP that manages voice services needs to treat reputation management as an ongoing operational responsibility, not a one-time setup item.

## How caller ID reputation actually works

When someone's phone rings, the decision about what the screen displays (the caller's name, a verified badge, a "Spam Likely" label, or nothing because the call was blocked) is made by a combination of systems that evaluate the incoming call in real time.

The carrier's own analytics engine evaluates the call based on STIR/SHAKEN attestation (covered in [Post 18](/blog/msp-stir-shaken)), calling patterns associated with the number, and any reputation data the carrier has for that number.

Third-party analytics companies like TNS (Transaction Network Services), Hiya, First Orion, and Nomorobo maintain their own databases of number reputation. Carriers license data from these companies to supplement their own analysis. The major wireless carriers each have relationships with one or more analytics providers, and the analytics that determine whether a call gets flagged vary by carrier.

The handset itself may apply additional filtering. Apple's Silence Unknown Callers feature on iOS, Google's call screening on Pixel phones, and third-party apps like Truecaller and RoboKiller all make independent decisions about how to handle incoming calls. These applications use their own databases, their own algorithms, and their own user-reported spam data.

The result is a multi-layered system where your client's call is evaluated by several independent entities, each with its own criteria, before it reaches the recipient. A number might show up clean on one carrier and flagged on another. It might be fine on AT&T but blocked by a third-party app that a particular recipient has installed. This fragmentation makes reputation management more complex but also more important, because you need to monitor across multiple systems rather than checking a single source.

## Why legitimate business calls get flagged

This is the question MSPs hear most often, and the answer is rarely simple. The root of it is that [STIR/SHAKEN verifies identity, not intent](/blog/stir-shaken-reality-2026), so carriers layer analytics engines on top, and those engines make mistakes. Legitimate business calls get flagged for a range of reasons, often in combination.

### Improper attestation

As covered in the [STIR/SHAKEN post](/blog/msp-stir-shaken), calls that receive partial (B) or gateway (C) attestation instead of full (A) attestation are more likely to be flagged. This happens when the caller ID number is not properly registered with the signing provider, when the number was ported from another carrier and the registration did not follow, or when the trunk provider cannot verify the caller's authorization to use the number.

This is the first thing to check when a client reports spam labeling. Verify the attestation level their calls are receiving. If it is anything other than full, work with the trunk provider to resolve it.

### Number registration gaps

Beyond STIR/SHAKEN registration, there are caller registry services that allow businesses to register their phone numbers and assert that they are legitimate business numbers. The most prominent is the Free Caller Registry (formerly known as the CNAM/caller ID registration ecosystem), but there are also carrier-specific registration programs.

Numbers that are not registered in these databases start from a neutral or negative baseline. The analytics engines do not know who owns the number, which means the number's reputation is determined entirely by its observed behavior. For a new number with no history, the algorithms may default to caution and flag it as unknown or potentially suspicious, especially if the calling pattern looks like it could be automated.

### High-volume patterns that look like robocalling

This is where legitimate business operations can accidentally trigger spam detection. A sales team that makes 200 outbound calls per day from a single number exhibits a calling pattern that looks, to an analytics engine, very similar to a robocaller. Short call durations (because many calls go to voicemail), high call volume, and calls to numbers that never call back are all signals that analytics engines use to identify robocalling. Legitimate sales activity shares many of these characteristics.

The same applies to appointment reminder systems, collections calls, survey operations, and any other high-volume outbound calling. The behavior pattern matches what the algorithms are designed to detect, even when the calls are legitimate and wanted.

### Numbers previously used by bad actors

Phone numbers get recycled. When a number is released by one customer and assigned to another, the new customer inherits whatever reputation the previous owner left behind. If the previous owner was a robocaller, or if the number was spoofed by robocallers (which does not require the number to have ever been legitimately assigned to them), the number may carry a negative reputation that has nothing to do with your client.

This is particularly common with new DID blocks from trunk providers. The provider may acquire a block of numbers that were previously in use elsewhere, and some of those numbers may have accumulated negative reputation. Your client gets assigned a "new" number that is already flagged as spam in multiple databases.

### Client behavior that crosses lines

Sometimes the flagging is not an error. A client may be making calls that, intentionally or not, violate calling regulations or best practices. Outbound campaigns without proper consent, calling numbers on the Do Not Call registry, or using auto-dialers to call cell phones without prior express consent are all behaviors that generate complaints, and complaints drive reputation scores down.

This puts the MSP in a difficult position, because the client may not realize they are doing anything wrong, or they may understand the rules and be pushing the boundaries. Either way, the reputation consequences fall on the phone numbers you manage.

## Monitoring reputation

Effective reputation management starts with monitoring. You need to know when a client's numbers are flagged before the client discovers it through declining answer rates and frustrated feedback from their contacts.

### Checking against major databases

Several services allow you to check how a phone number is being categorized:

**Free Caller Registry** allows businesses to register their numbers and check their status across participating analytics providers. It is free and should be a baseline part of your number management process.

**Carrier-specific portals.** The major carriers (AT&T, T-Mobile, Verizon) have programs and portals where businesses can register numbers and dispute spam labels. Each carrier's program has different requirements and processes, and you may need to register with each one independently.

**Third-party analytics providers.** Companies like TNS, Hiya, and First Orion offer dashboards and APIs that show how numbers are scored. Some of these services are available directly; others are accessible through your trunk provider's platform.

**Manual testing.** The low-tech approach: call a number from the client's line and see what the recipient's phone displays. Test across carriers (call an AT&T cell phone, a T-Mobile cell phone, a Verizon cell phone) because the display can vary by carrier. This is not scalable, but it is a useful spot-check.

### Watching answer rates

If you have access to call detail records and reporting through your trunk provider or wholesale platform, monitor answer rates over time. A sudden decline in answer rates for a specific number or a specific client is often the first signal that reputation has degraded. The analytics engines flagged the number before anyone reported it to you.

This kind of monitoring ties into the [proactive monitoring](/blog/msp-proactive-monitoring) practices we discussed earlier in the series. Adding caller reputation metrics to your regular review cycle gives you visibility into problems before they become client escalations.

### Client feedback

Sometimes the first indication is a client telling you that their customers mentioned seeing a spam label. Take these reports seriously and investigate immediately. If one customer mentioned it, many others saw it and simply did not answer. The reported complaint is the tip of an iceberg of missed connections.

Build this into your support workflow. When a client reports a spam labeling issue, have a documented process: check attestation level, check registration status, check the number against major databases, review calling patterns, and escalate to the trunk provider if the issue is on their side.

## Remediation

When a number is flagged, getting it unflagged requires addressing the root cause and then working through the various systems to update the reputation.

### Registering with caller registry services

If the number is not registered with the Free Caller Registry and the carrier-specific registration programs, start there. Registration does not guarantee that a flagged number will be unflagged, but the absence of registration makes it harder to dispute a spam label. The registration creates a record that the number belongs to a legitimate business and provides a point of contact for disputes.

### Working with the trunk provider on attestation

If the number is receiving less than full attestation, work with your trunk provider to resolve it. This usually means ensuring the number is properly registered in the provider's STIR/SHAKEN system and that the provider's signing infrastructure is correctly attesting calls from that number. If the number was ported in, the porting process may not have automatically updated the STIR/SHAKEN registration, and a manual update may be needed.

### Disputing spam labels

Each carrier and analytics provider has a dispute process for challenging spam labels. The process typically involves submitting information about the business that owns the number, demonstrating that the calling activity is legitimate, and requesting a review. Dispute resolution timelines vary. Some providers resolve disputes in days, others take weeks.

Be prepared for the dispute process to be frustrating. You may need to submit information to multiple entities (the carrier, the analytics provider, the app developer) because each one maintains its own database and its own scoring. A successful dispute with one entity does not automatically propagate to others.

### Getting new numbers

In some cases, the fastest path to clean calling is to replace the flagged number with a new one. This is a last resort because it means the client loses a number they may have had for years, and it creates disruption for anyone who has that number in their contacts. But if a number has been thoroughly poisoned, whether by its previous owner's behavior or by persistent spoofing, the effort required to rehabilitate it may exceed the effort required to transition to a new number.

If you go this route, make sure the new number does not have its own reputation problems before assigning it. Check new DIDs against spam databases before provisioning them for a client. Some trunk providers will work with you to select numbers that have clean history.

### Adjusting calling practices, not spreading the traffic

If the flagging is related to high-volume calling patterns, resist the tempting shortcut: rotating numbers or spreading the same call volume across a pool of DIDs to dilute the per-number statistics. Analytics engines specifically look for that pattern: it is called snowshoeing, and it is a hallmark of actual robocall operations. Spreading traffic to evade scoring makes the client look more like a bad actor, not less, and it throws away the stable per-number history that legitimate high-volume callers rely on to keep their reputation clean.

The remediation that actually works addresses the substance of the calling, in line with the FCC's caller ID authentication framework: make sure the client is presenting only numbers they are authorized to use, work with the trunk provider to get appropriate A-level attestation on those numbers, register the business and its campaigns with the caller registry and analytics programs, honor consent and opt-out requests so complaint rates stay low, investigate whether a customer's system has been compromised and is originating traffic they do not know about, and use each terminating carrier's and analytics provider's redress channel to dispute genuinely mislabeled calls.

Some businesses use a dedicated outbound calling number that is separate from their main inbound number, so that callback traffic and outbound campaigns build distinct histories. That is a reasonable operational separation (one number per purpose, registered and attested), and it is different in kind from rotating through numbers to stay under the radar.

## TCPA and business calling practices

The Telephone Consumer Protection Act (TCPA) predates the STIR/SHAKEN era, but it is deeply relevant to caller reputation because TCPA violations generate the complaints that drive reputation scores down.

The TCPA restricts how businesses can use automated dialing systems and prerecorded messages to contact consumers. The rules are detailed and have been the subject of extensive litigation, but the high-level principles that MSPs should understand include:

**Prior express consent.** Calling or texting a consumer's cell phone using an automatic telephone dialing system or prerecorded voice generally requires the consumer's prior express consent. For marketing calls, that consent must be in writing (which includes electronic consent). The definition of "automatic telephone dialing system" has been the subject of significant legal debate, but the safest approach is to assume that any system that dials numbers from a list without manual intervention is covered.

**Do Not Call compliance.** Businesses that make telemarketing calls must maintain and honor internal Do Not Call lists, and must scrub their calling lists against the National Do Not Call Registry maintained by the FTC. Calling a number on the Do Not Call Registry without an applicable exemption is a violation.

**Revocation of consent.** Consumers can revoke their consent to receive calls at any time, and the business must honor the revocation. A system that continues to call a consumer who has asked to be removed is generating violations that will eventually generate complaints that will eventually degrade the number's reputation.

**Business-to-business exemptions.** The TCPA's restrictions on autodialed calls and the Do Not Call Registry apply primarily to calls to consumers. Calls to businesses have different (generally less restrictive) rules. But the distinction between a consumer number and a business number is not always clear, especially with cell phones that are used for both personal and business purposes.

For MSPs, the TCPA relevance is twofold. First, if your clients are conducting outbound calling campaigns, their compliance with the TCPA directly affects the reputation of the phone numbers you manage. A client that ignores Do Not Call requests and generates complaints will damage their numbers' reputation, and by extension, your reputation as their voice provider. Second, the TCPA creates liability exposure for businesses that violate it, and clients who are not aware of their obligations may look to you for guidance because you are the technology provider.

You do not need to be a TCPA expert, and giving legal advice on TCPA compliance to your clients is not your role. But you should understand the basics well enough to recognize when a client's calling practices might be creating reputation risk, and you should be prepared to suggest they consult with their own legal counsel about their outbound calling practices.

## Ongoing responsibility: this is not set-and-forget

The theme running through this entire compliance section of the series is that voice service obligations are ongoing. They do not end when you provision the trunk, configure the PBX, and port the numbers. The regulatory filings need to be maintained. The STIR/SHAKEN registration needs to stay current. The caller reputation needs to be monitored. The calling practices need to be compliant.

For MSPs who are accustomed to the managed services model, this should feel familiar. You do not patch a server once and walk away. You do not configure a firewall once and forget about it. You maintain, monitor, and adapt over time because the landscape changes. Caller reputation management is the same. It is an ongoing managed service responsibility.

Build it into your operations:

**Quarterly reputation checks.** Check your clients' primary outbound numbers against the major spam databases and carrier lookup tools. Flag any numbers that have been negatively categorized and initiate remediation.

**Provisioning checklists.** When you add a new number for a client, include caller registry registration, STIR/SHAKEN registration verification, and a clean-history check as standard provisioning steps.

**Client onboarding.** When you onboard a new voice client, discuss their outbound calling practices. Understand whether they do high-volume outbound calling, whether they use automated dialing, and whether they have TCPA compliance processes in place. Set expectations that their calling practices affect their phone number reputation.

**Incident response.** Have a documented process for when a client reports spam labeling. Know the steps: check attestation, check registration, check databases, review calling patterns, escalate to trunk provider, file disputes with carriers and analytics providers.

**Renewal tracking.** Track the deadlines for your RMD filing (filers recertify annually by March 1 and must update changed information within 10 business days, per the FCC's RMD filing rules in DA 26-72), your upstream providers' RMD status, your STIR/SHAKEN certificates (if you have your own), and any carrier-specific registrations. Missing a deadline can have immediate operational consequences.

## Wrapping up the series

This is the twentieth and final post in the MSP's Guide to VoIP. Over the course of this series, we have covered the full arc of building and operating a voice offering within a managed services business.

We started with the [fundamental question of whether voice makes sense for your MSP](/blog/msp-should-you-offer-voice) and walked through the [service models](/blog/msp-voice-service-models) that determine how deep your involvement goes. We covered [client expectations](/blog/msp-voice-support-expectations) and the reality that voice support is different from data support in ways that affect your operations, your staffing, and your client relationships. We worked through the [network assessment](/blog/msp-network-assessment) that needs to happen before you deploy a single phone, and the [platform selection](/blog/msp-choosing-voip-platform) process that determines what your voice offering is built on.

We got into the operational details: [trunk configuration](/blog/msp-trunk-configuration), [proactive monitoring](/blog/msp-proactive-monitoring), [vendor relationships](/blog/msp-vendor-relationships), and the specialized requirements of [contact center](/blog/msp-contact-center) environments. And in these final four posts, we covered the regulatory landscape that every voice provider needs to understand, from [FCC classification](/blog/msp-regulatory-landscape) to [STIR/SHAKEN](/blog/msp-stir-shaken) to the [Robocall Mitigation Database](/blog/msp-robocall-mitigation-database) to the ongoing work of maintaining caller reputation.

The through-line across all twenty posts is that voice is a serious commitment that rewards serious preparation. The MSPs that succeed with voice are the ones that invest in understanding the technology, build the right operational processes, hire or train for the right skills, and stay on top of the ongoing obligations. The ones that struggle are the ones that treated voice as just another product to resell without appreciating how different it is from the rest of their stack.

If you have read this far, you have a comprehensive foundation for making informed decisions about voice in your MSP. Whether you are just starting to evaluate the opportunity, actively building your voice offering, or looking to improve an existing offering, the information in this series gives you the context to do it well.

Voice is hard. But it is hard in ways that are knowable, manageable, and ultimately rewarding when you get it right. Your clients need their phones to work, and they need someone they trust to make that happen. If you decide to be that someone, do it with your eyes open and your operations solid. The rest follows from there.

---

## Series: Your Office Network: The Part Nobody Thinks About

A 10-part series on the internal network layer that makes or breaks your call quality. Covers switches, VLANs, QoS, cabling, routers, WiFi, PoE, and knowing when to upgrade.

### Part 1: What's in Your Network Closet and What It All Does

URL: https://voiptest.com/blog/office-network-closet
Published: 2026-03-29
Tags: office-network, network-equipment, modem, router, switch, access-point

*Your Office Network: Part 1 of 10*

If you have ever walked into that closet, the one with the blinking lights and the tangle of cables that nobody is allowed to touch, and felt a vague unease about what all of it actually does, this post is for you.

The equipment in that closet is the foundation of every phone call, every video meeting, every email, and every file transfer that happens in your office. When everything works, nobody thinks about it. When something breaks, everyone thinks about it at the same time.

Understanding what each piece of equipment does, how they connect to each other, and where things can go wrong is the first step toward having a network that reliably supports your business. You do not need to become a network engineer. You just need to know enough to ask the right questions and recognize when something is not right.

## The chain

Every piece of data that moves between the internet and a device on your desk follows a specific path through a series of equipment. The chain looks like this:

**ISP connection → Modem or ONT → Router → Switch → Patch panel → Wall jack → Your device**

Some offices skip a step or two. Some have extra pieces in between. But this is the general flow, and understanding each link in the chain is what the rest of this post covers.

The important thing to know upfront is that every link in this chain is a potential point of failure. A problem at any single point can degrade or break everything downstream of it. When your [VoIP calls sound choppy](/blog/choppy-robotic-audio) or you get [one-way audio](/blog/one-way-audio), the cause could be hiding at any point along this path.

## The modem or ONT

The first piece of equipment inside your building is usually either a modem or an ONT (optical network terminal). Which one you have depends on what type of [internet connection](/blog/isp-foundation) you are using.

### Cable modem

If you have [cable internet](/blog/cable-internet), you have a cable modem. This is the box where the coaxial cable from your internet provider plugs in on one side, and an Ethernet cable comes out the other side. The modem's job is translation. It converts the signal format that your cable provider uses on their coaxial network into standard Ethernet that your router can understand.

Cable modems vary in quality and capability. Older modems may only support DOCSIS 3.0 while your provider has upgraded to DOCSIS 3.1, which means you could be leaving performance on the table. Some modems are provided by the ISP and some are customer-owned. Either way, it is worth knowing what model you have and whether it supports the speeds you are paying for.

The modem itself rarely causes VoIP-specific problems, but it can be the source of general connectivity issues. A modem that overheats, has degraded components, or is running outdated firmware can introduce packet loss or intermittent drops that affect everything, including voice calls.

### Fiber ONT

If you have [fiber internet](/blog/fiber-internet), you have an ONT instead of a modem. The ONT does the same fundamental job, just with different technology. It converts the light signals traveling over the fiber optic cable into electrical signals on an Ethernet cable.

ONTs are typically installed and owned by the fiber provider. They are usually mounted on a wall near where the fiber enters the building. Most are fairly reliable, passive devices. The main thing that goes wrong with them is power loss, since they need electricity to operate. If your power goes out, your ONT goes down, and so does your internet, even though the fiber itself is unaffected. Some businesses install a small uninterruptible power supply (UPS) for the ONT specifically for this reason.

### DSL modem

If you are on a [DSL connection](/blog/dsl-connection), you have a DSL modem. Same concept, different technology. It converts the signal on the telephone copper pair into Ethernet. DSL modems tend to run warm and can develop issues over time, especially in environments with poor ventilation.

### Combination devices

Some ISPs provide a single box that combines the modem and router into one device. These are common in residential service and lower-tier business packages. They technically work, but they give you less control and less visibility into what is happening on your network. If your ISP provided an all-in-one unit and you are having persistent VoIP issues, separating the modem and router functions into dedicated devices is a common first step that IT professionals recommend.

## The router

The router is arguably the most important piece of equipment in your network closet. It sits between your modem (the internet side) and everything else in your office (the local side), and it makes decisions about every single packet of data that enters or leaves your network.

### What the router does

The router has several jobs.

**Routing.** It directs traffic between your local network and the internet. When your phone sends a voice packet to your VoIP provider, the router sends it out through the modem. When a packet comes back, the router figures out which device on your network should receive it and delivers it there.

**NAT (Network Address Translation).** Your ISP gives you one public IP address (sometimes a small handful), but you have dozens of devices inside your office. The router maintains a translation table that lets all of those devices share a single public address. This is essential for normal operation, but it can also be a source of VoIP problems. [NAT traversal](/blog/sip-nat-traversal) is one of the most common causes of [one-way audio](/blog/one-way-audio) and failed calls.

**Firewall.** The router inspects incoming traffic and blocks anything that does not look like a response to something your network requested. This is critical for security, but firewalls that are too aggressive can interfere with VoIP traffic, which has unusual traffic patterns compared to web browsing or email.

**DHCP.** The router typically assigns IP addresses to devices on your network automatically. This is usually invisible until it is not, like when two devices get the same address and one of them stops working intermittently.

**Quality of Service.** On a properly configured router, [Quality of Service](/blog/quality-of-service-explained) rules prioritize voice traffic over less time-sensitive data. This is the single most impactful setting for VoIP quality on your local network. Without it, your phone calls compete equally with file downloads, cloud backups, and software updates for the available bandwidth.

### Why the router matters so much for VoIP

The router is the bottleneck where your fast internal network meets your slower internet connection. If your office has gigabit Ethernet internally but a 100 megabit internet connection, the router is the funnel where all that traffic has to squeeze through. During busy periods, this is where congestion happens, and congestion is what causes [jitter](/blog/what-is-jitter-and-why-it-matters) and [packet loss](/blog/understanding-voip-packet-loss) on your calls.

A consumer-grade router handling traffic for 20 or 30 devices will struggle. Its processor is not fast enough, its memory is limited, and its Quality of Service implementation is either nonexistent or rudimentary. Business-grade routers are built for this workload and provide the controls you need to protect voice traffic.

## The switch

If the router is the brain of your network, the switch is the nervous system. It provides the physical Ethernet ports where all of your devices connect, and it moves traffic between them.

When your desk phone needs to communicate with the router (to send voice packets to the internet), the switch handles that connection. When your computer needs to reach a printer on the same network, the switch handles that too, without the traffic ever needing to touch the router.

Switches come in two main varieties: unmanaged and managed.

**Unmanaged switches** are simple. You plug in cables and they work. There is no configuration, no login screen, no settings to adjust. They treat all traffic equally, forwarding packets as fast as they can without any prioritization or segmentation. For a very small office with a handful of devices, an unmanaged switch is often sufficient. But as soon as VoIP quality becomes a concern, the lack of traffic prioritization becomes a liability.

**Managed switches** add a layer of intelligence. They let you configure VLANs (virtual local area networks) to separate voice and data traffic, enable Quality of Service to prioritize voice packets, monitor port-level traffic for diagnostics, and provide PoE (Power over Ethernet) to power phones directly through the network cable.

We cover switches in much more detail in [Part 3](/blog/office-network-switches) of this series, and VLANs in [Part 4](/blog/office-network-vlans).

## Wireless access points

Wireless access points provide Wi-Fi for laptops, phones, tablets, and other devices that are not connected with a cable. In some offices, the router has built-in Wi-Fi. In larger offices, dedicated access points are mounted on ceilings or walls and wired back to the switch.

For general office work, Wi-Fi is fine. For VoIP, it is a significant risk factor. Wireless is a shared medium with inherent variability in latency and reliability. A wired connection to a switch provides consistent, predictable performance. A wireless connection provides variable performance that depends on how many devices are active, what the radio environment looks like, and where the device is physically located.

This does not mean you cannot take calls on Wi-Fi. It means you should understand the trade-offs. We dedicate the entire [next post](/blog/office-network-wired-vs-wifi) to this question because it is the single most impactful decision for VoIP quality in most offices. There is also a standalone deep dive on [wired vs. Wi-Fi for VoIP](/blog/wired-vs-wifi-for-voip) if you want the full technical breakdown.

## The patch panel

The patch panel is the least glamorous piece of equipment in the closet, and also one of the most important for maintainability. It is a flat panel with rows of numbered ports, usually mounted on a rack or wall.

Here is what it does. The Ethernet cables that run through your walls to the wall jacks at each desk are permanent installations. They are run through conduit, stapled along joists, and terminated at both ends. You do not want to be plugging and unplugging these cables regularly because the connections at the cable ends wear out and the cables are difficult or impossible to replace without opening walls.

The patch panel solves this. The permanent in-wall cables terminate on the back of the patch panel. On the front, you use short patch cables to connect each port to the corresponding port on your switch. If you need to move someone to a different switch port, you move the patch cable. If a patch cable goes bad, you replace a $3 cable instead of re-running a $300 cable through the wall.

The patch panel itself is passive. There are no electronics, no power, no configuration. But bad terminations on the patch panel are a real and surprisingly common source of intermittent connectivity problems. A pin that is not making solid contact can cause the kind of sporadic [packet loss](/blog/understanding-voip-packet-loss) that drives people crazy because it comes and goes unpredictably.

If you are experiencing intermittent network problems that seem to affect specific desks or jacks, the patch panel terminations are worth checking.

## Wall jacks and cables

At the other end of the in-wall cables are the wall jacks at each desk. An Ethernet cable runs from the wall jack to the device, whether that is a phone, a computer, or both.

Most VoIP desk phones have two Ethernet ports on the back. One connects to the wall jack (labeled "LAN" or "Network" or with an icon of a globe). The other connects to the computer (labeled "PC" or "Computer" or with an icon of a monitor). This passthrough design lets the phone and computer share a single cable run from the closet. The phone sits in the middle, acting as a tiny switch. This is a standard and reliable configuration, and it means you do not need two cable runs to every desk.

The cables themselves matter more than people realize. Damaged cables, cables that are too long, cables that run alongside electrical wiring, and cables with a lower category rating than the network requires can all cause problems. Cat 5e is the minimum for gigabit Ethernet. If your building has old Cat 5 (not 5e) cabling, those runs should be on the list to replace.

## How it all connects

Let's trace the path of a voice packet from your desk phone to the internet.

You are on a call. You say something. The phone captures the audio, compresses it using a codec, and wraps it in a data packet. The packet leaves the phone through the Ethernet cable, travels to the wall jack, through the in-wall cable to the patch panel, through the patch cable to the switch.

The switch reads the destination address on the packet and forwards it to the port where the router is connected. The router sees that the packet is destined for an address on the internet (your VoIP provider), applies any Quality of Service rules, performs the NAT translation from your internal address to your public address, and sends it out through the modem.

The modem converts the signal for your ISP's network, and the packet begins its [journey across the internet](/blog/the-internet-path) to your VoIP provider.

Coming back, the reverse happens. A packet arrives from your VoIP provider, through the modem, to the router. The router's NAT table tells it which internal device this packet belongs to. It forwards the packet to the switch, which delivers it through the patch cable, through the in-wall cable, out the wall jack, and down the cable to your phone. The phone decodes the audio and plays it through the speaker.

This entire round trip takes somewhere between 20 and 150 milliseconds depending on where your VoIP provider is and how your network is configured. Every piece of equipment in the chain adds a small amount of processing time. On a healthy network, each local device adds well under a millisecond. But problems at any point, a congested router, an overloaded switch, a bad cable, can add delay, [jitter](/blog/what-is-jitter-and-why-it-matters), or outright [packet loss](/blog/understanding-voip-packet-loss) that degrades the call.

## Every link is a potential problem

This is the key takeaway. Your network is a chain, and every link in that chain can introduce problems.

A flaky modem causes intermittent drops. An undersized router adds latency under load. An unmanaged switch cannot prioritize voice traffic. A bad patch panel termination causes sporadic packet loss. A damaged cable creates intermittent errors. A wireless connection adds unpredictable jitter.

The good news is that this is also the part of the [voice path you control](/blog/your-local-network). You own this equipment. You can configure it, upgrade it, and replace it. Problems that originate inside your building are the most fixable problems in the entire chain.

The rest of this series walks through the most important decisions and configurations for each piece. If you want a quick read on whether your current setup can handle VoIP, our [Bandwidth Calculator](/tools/bandwidth-calculator) can estimate how much capacity your office actually needs based on your call volume and device count. We start with the single most impactful choice most offices face: whether to run their voice devices on wired Ethernet or Wi-Fi.

## What comes next

The next post tackles the wired versus Wi-Fi question head on. It is the single decision that affects VoIP quality more than almost anything else in your office, and the answer is more nuanced than just "always use wired."

---

*This is Part 1 of the [Your Office Network](/blog?category=guides) series. [Part 2: Wired Versus WiFi: Why This Decision Matters More Than You Think](/blog/office-network-wired-vs-wifi) covers the most important infrastructure decision for voice quality.*

---

### Part 2: Wired Versus WiFi: Why This Decision Matters More Than You Think

URL: https://voiptest.com/blog/office-network-wired-vs-wifi
Published: 2026-03-29
Tags: office-network, wired-ethernet, wifi, jitter, call-quality

*Your Office Network: Part 2 of 10*

In the [previous post](/blog/office-network-closet), we walked through every piece of equipment between your internet connection and your desk. Now we are going to focus on the single decision that has more impact on VoIP call quality than almost anything else in your office: whether your voice devices are connected with a cable or over Wi-Fi.

This is not a nuanced, "it depends" kind of answer. For voice traffic specifically, wired Ethernet is better. Meaningfully, measurably, consistently better. The rest of this post explains why, puts real numbers on the difference, and then addresses what to do when running a cable genuinely is not an option.

## How wired Ethernet works

An Ethernet cable between your phone and a switch is a dedicated, point-to-point connection. The phone has the full bandwidth of that link available to it at all times. No other device shares it. No other device can interfere with it. The signal travels over copper (or fiber, in some cases) in a controlled, shielded environment.

When your phone sends a packet, it goes directly to the switch with no contention, no waiting, no retransmission. The switch reads the destination and forwards it, typically in under a microsecond. The round-trip time for a packet to travel from your phone to the switch and back is measured in fractions of a millisecond.

The result is consistency. A wired Ethernet connection delivers the same performance at 9 AM on a quiet Monday morning as it does at 2 PM on a busy Thursday afternoon. Measure the [jitter](/blog/what-is-jitter-and-why-it-matters), which is the variation in packet arrival times, on a healthy wired access link and you will typically see well under 1 millisecond. Packet loss on that link is effectively zero unless there is a hardware problem or a cable issue.

This consistency is exactly what voice traffic needs. As we covered in [why voice is hard](/blog/why-voice-is-hard), the human ear is extraordinarily sensitive to irregularity. It is not the average latency that kills call quality; it is the spikes. And a wired access link simply does not produce spikes under normal operation.

One important caveat: this describes the link between your device and its switch. Wired traffic can still queue further along the path: at an oversubscribed uplink between switches, or at the WAN egress where a gigabit LAN funnels into a much smaller internet connection. Going wired removes the shared-medium problem at the access layer; it does not exempt you from congestion at the bottlenecks, which is why [QoS](/blog/office-network-qos) still matters even on an all-wired network.

## How Wi-Fi works and why it is different

Wi-Fi seems like the same thing without the cable. Your device sends data, the access point receives it, and it reaches the network. But the underlying mechanics are fundamentally different, and those differences have consequences that matter for real-time audio.

### It is a shared medium

A wired connection is a private conversation between your device and the switch. A Wi-Fi connection is more like a conference call where everyone has to take turns talking.

Every device connected to the same access point shares the same radio channel. The Wi-Fi protocol (technically, CSMA/CA) requires each device to listen before transmitting. If the channel is busy, the device waits. If two devices transmit at the same time and collide, both back off for a random interval and try again. The more devices on the channel, the more waiting, the more collisions, the more retransmissions.

This means that even if your phone only needs a tiny amount of bandwidth for a voice call, it still has to wait its turn when 25 other devices are also trying to send data. That waiting time is variable and unpredictable, which is the definition of [jitter](/blog/what-is-jitter-and-why-it-matters).

### The air is noisy

The radio frequencies that Wi-Fi uses, particularly the 2.4 GHz band, are shared with an enormous number of other devices and technologies. Bluetooth headsets, wireless mice and keyboards, microwave ovens, baby monitors, cordless phones (the old kind), wireless security cameras, and your neighbors' Wi-Fi networks are all operating in or near the same frequency range.

Interference from these sources corrupts packets in transit. When a Wi-Fi packet is corrupted, the receiving device does not get it and does not send an acknowledgment back. The sending device waits, times out, and retransmits. This adds latency that varies depending on the radio environment at that particular moment, which is, again, jitter.

### Signal strength varies constantly

Wi-Fi signal strength depends on distance, obstacles, and the physical environment. A phone sitting three feet from an access point with clear line of sight gets an excellent signal. The same phone on a desk 40 feet away, on the other side of two walls and a filing cabinet, gets a much weaker signal.

Weaker signal means lower data rates and higher error rates. The Wi-Fi system adapts by dropping to a lower modulation scheme that is more resilient but slower. And the signal strength is not static. People walking through the office, doors opening and closing, even changes in humidity can cause the signal to fluctuate. Each fluctuation can cause a momentary increase in errors and retransmissions.

### Roaming disruptions

In offices with multiple access points, devices sometimes switch from one access point to another as you move around or as signal conditions change. This handoff takes time. With older Wi-Fi standards, it can cause a disruption of several hundred milliseconds. With modern fast roaming (802.11r fast transition, assisted by 802.11k neighbor reports and 802.11v steering), the disruption is shorter, but it is not zero.

If a roaming event happens during an active call, you get a brief audio dropout. Most people experience this as a momentary gap in the conversation. It is not catastrophic, but it is the kind of thing that wired connections simply never produce.

## The numbers

The figures below are representative measurements from typical office networks during business hours: the kind of results you should expect to see when you measure your own, not thresholds from a standard. Your environment will produce its own numbers, which is exactly why measuring beats quoting: run a [VoIP quality test](/tools/voip-test) on both a wired and a Wi-Fi device and compare.

### Jitter

Measured on a wired Ethernet connection to a managed switch, jitter typically comes in at 0.5 to 1 millisecond. It stays in that range almost all the time, regardless of how busy the network is, because the access link is not shared. (What test tools report is [the RFC 3550 interarrival jitter estimate](https://datatracker.ietf.org/doc/html/rfc3550#appendix-A.8), a running statistical average, not a worst-case spike, which is worth remembering when comparing numbers.)

On Wi-Fi under normal load (10-15 devices per access point, moderate traffic), measurements commonly show 10 to 30 milliseconds. Most VoIP playout buffers can absorb this, so calls usually sound okay; the audible impact of jitter always depends on how much delay the jitter buffer adds and how many late packets it has to discard, not on the raw number crossing some universal line.

On Wi-Fi under heavy load (25+ devices, video calls, file transfers, people streaming), measured jitter regularly spikes to 50 milliseconds or higher. At these levels, typical jitter buffers start discarding packets because they arrive too late to play back. The result is [choppy, robotic audio](/blog/choppy-robotic-audio).

The difference between 1 millisecond of jitter and 50 milliseconds of jitter is the difference between perfect call quality and a conversation that is frustrating to have.

### Packet loss

On a healthy wired access link, measured packet loss is effectively 0%. If you are measuring loss on the link between a device and its switch, something is wrong with the cable, the switch, or the device; it is not a characteristic of the technology. (Wired traffic can still be dropped further along the path when a congested uplink or WAN egress queue overflows, but that is a congestion problem QoS addresses, not a property of the wire.)

On Wi-Fi under good conditions, measured packet loss runs 0.1% to 0.5%. That sounds negligible, but it means one to five out of every thousand packets do not arrive. For a voice call sending 50 packets per second, that is occasional brief gaps in the audio. Most codecs can conceal occasional isolated losses at this level reasonably well.

On Wi-Fi under stress, measured loss can spike to 2% or higher during interference events or heavy congestion, and Wi-Fi loss tends to come in bursts, which is harder on concealment than the same percentage spread evenly. Around that level, packet loss concealment audibly breaks down. This is the kind of thing you hear on that [afternoon call that sounds terrible](/blog/afternoon-call-quality) even though the morning calls were fine.

### Latency

Wired connections add less than 1 millisecond of latency between the device and the switch. Measurements on Wi-Fi typically show an added 3 to 10 milliseconds under light load and 20 to 50 milliseconds under heavy load. This is on top of the latency from the rest of the network path (router, internet, VoIP provider).

By itself, an extra 10 or 20 milliseconds of latency might not be a deal-breaker. But latency compounds. If Wi-Fi adds 20 milliseconds, and your router adds 5 milliseconds because it is not prioritizing voice, and the internet path adds 40 milliseconds, and the far end has a similar setup, you are approaching 150 milliseconds of one-way mouth-to-ear delay, [the planning boundary ITU-T G.114 cites for conversational speech](https://www.itu.int/rec/T-REC-G.114/en). That is a transmission-planning guideline, not a cliff where audio suddenly fails, but as total one-way delay climbs into that territory people increasingly start talking over each other because the delay is perceptible. We covered this pattern in [audio delay and talking over each other](/blog/audio-delay-talking-over).

## The recommendation

If a device is used for voice calls, it should be on a wired Ethernet connection if at all possible. This includes desk phones, computers running softphone applications, and headsets that connect to a computer which is itself on the network.

This is not about being anti-wireless. Wi-Fi is great for laptops, tablets, and phones that need to move around. It is great for email, web browsing, and even video streaming, because those applications can tolerate jitter and brief interruptions without the user noticing. Real-time voice is different. It has no tolerance for inconsistency, and wired Ethernet delivers consistency that Wi-Fi cannot match.

The cost difference is negligible. A Cat 6 Ethernet cable from the wall jack to a phone costs a few dollars. Running a new cable from the network closet to a desk, if one does not already exist, costs more, but it is a one-time investment that eliminates the Wi-Fi variable permanently.

In most offices, the infrastructure for wired connections already exists. The building has cable runs to the desks, there are wall jacks, there is a patch panel in the closet. The phones just need to be plugged in. The problem is usually not that wired is impossible, it is that someone set up the phones on Wi-Fi because it was easier at the time and nobody realized the trade-off they were making.

## When Wi-Fi is unavoidable

Sometimes running a cable genuinely is not practical. Historic buildings where you cannot open walls. Temporary offices. Shared coworking spaces. Employees who move between desks regularly. There are legitimate reasons why some voice devices end up on Wi-Fi.

If that is your situation, here is how to make the best of it.

### Use 5 GHz or 6 GHz, never 2.4 GHz

The 2.4 GHz band has three non-overlapping channels. In any urban or suburban environment, those three channels are saturated with signals from neighboring networks and other devices. The 5 GHz band has over 20 non-overlapping channels, far less interference, and higher throughput. The 6 GHz band (Wi-Fi 6E) is even better, with more channels and virtually no legacy device interference today.

The trade-off is range. 5 GHz and 6 GHz signals do not penetrate walls as well as 2.4 GHz. But for voice quality, the reduction in interference far outweighs the reduction in range. If range is a problem, the answer is more access points, not falling back to 2.4 GHz.

Configure your access points and voice devices to prefer 5 GHz. Many access points have a band steering feature that nudges dual-band devices toward 5 GHz automatically.

### Enable WMM (Wi-Fi Multimedia)

WMM is a Wi-Fi Alliance specification that provides basic traffic prioritization over the air. It defines four access categories: voice, video, best effort, and background. When WMM is enabled, voice-tagged traffic gets priority access to the wireless medium, reducing the wait time caused by contention.

Most modern access points support WMM and have it enabled by default. Verify that it is on and that your VoIP devices are correctly tagging their traffic so it lands in the voice category: in practice that means marking voice packets with DSCP EF (46), the RFC 4594 telephony class, and then confirming the access point actually maps EF to the WMM voice category. That mapping is not the default: the common shortcut of taking the DSCP's top three bits lands EF in the video category instead, and [RFC 8325 on mapping DSCP to 802.11](https://www.rfc-editor.org/rfc/rfc8325.html) exists precisely to recommend the corrected EF-to-voice mapping.

WMM helps, but it is not magic. It reduces contention delay but cannot eliminate the fundamental variability of a shared radio medium. Think of it as the difference between bad and less bad, not between bad and good.

### Limit clients per access point

The more devices sharing an access point, the more contention and the more jitter. For environments where voice quality matters, aim for no more than 15 to 20 devices per access point, and fewer if those devices are generating heavy traffic like video calls.

This usually means deploying more access points at lower power rather than fewer access points at high power. Each access point covers a smaller area but serves fewer clients with better performance.

### Ensure strong coverage

A voice device with a weak Wi-Fi signal is a voice device with unreliable audio. Conduct a basic site survey to identify dead spots and weak areas. Every location where someone might take a call should have strong, stable signal from at least one access point.

### Consider Wi-Fi 6 (802.11ax) or Wi-Fi 6E

Wi-Fi 6 introduced several technologies that specifically help in dense environments. OFDMA (orthogonal frequency-division multiple access) allows an access point to communicate with multiple devices simultaneously rather than one at a time. Target wake time reduces contention from idle devices. BSS coloring helps manage interference from neighboring networks.

These improvements reduce jitter and contention meaningfully compared to Wi-Fi 5 (802.11ac). If you are stuck with Wi-Fi for voice and your access points are older than Wi-Fi 6, upgrading them is one of the highest-impact changes you can make.

Wi-Fi 6E adds the 6 GHz band, which is currently uncrowded and provides the best wireless experience available. If your voice devices support 6 GHz, this is the best wireless option.

## The "it works fine on Wi-Fi" trap

You will hear people say their VoIP works perfectly on Wi-Fi. And they might be right, in their specific situation. A home office with one person, one access point, and a handful of devices on a 5 GHz channel will produce excellent Wi-Fi performance. A single user in a quiet part of the office near an access point will have a good experience.

The problem is that these conditions do not represent the worst case. They represent the best case. Wi-Fi performance degrades as load increases, as interference increases, and as environmental conditions change. The call that sounds great at 9 AM when the office is half empty may sound terrible at 2 PM when everyone is back from lunch and running video calls and syncing files.

When people say "Wi-Fi works fine," what they often mean is "I have not noticed a problem yet." The problems tend to surface gradually, as the office grows, as more devices are added, as usage patterns shift. By the time the [afternoon call quality](/blog/afternoon-call-quality) problem is obvious, the root cause is buried under months of incremental changes.

Testing under realistic conditions, during peak load, over a meaningful time period, is the only way to know whether your Wi-Fi can actually handle voice traffic reliably. Running a [VoIP quality test](/tools/voip-test) from a WiFi-connected device during your busiest hours will show you exactly what your calls are experiencing.

## The bottom line

Wired Ethernet gives you consistency. Wi-Fi gives you convenience. For voice, consistency wins.

If you are setting up a new office, experiencing call quality problems, or just want to eliminate variables, plug your voice devices into the wall. Use Wi-Fi for everything that does not need real-time, low-latency delivery. This simple division solves more VoIP quality problems than any other single change.

## What comes next

Now that we have covered the connection between your device and the network, the next post dives into the equipment that ties everything together: the network switch. Switches are the unsung heroes of your network, and understanding the difference between a basic unmanaged switch and a properly configured managed switch can transform your network's ability to handle voice traffic.

---

*This is Part 2 of the [Your Office Network](/blog?category=guides) series. [Part 3: Switches: The Unsung Hero of Your Network](/blog/office-network-switches) explains why the right switch makes all the difference.*

---

### Part 3: Switches: The Unsung Hero of Your Network

URL: https://voiptest.com/blog/office-network-switches
Published: 2026-03-30
Tags: office-network, network-switch, managed-switch, unmanaged-switch, poe

*Your Office Network: Part 3 of 10*

In the [first post](/blog/office-network-closet) of this series, we walked through every piece of equipment in your network closet. The router got a lot of attention. The modem was easy to understand. The patch panel was straightforward. But the switch, the box with all the blinking lights and all the cables plugged into it, probably seemed like the least interesting piece in the closet.

It is actually the piece that ties everything together. And for offices running VoIP, the type of switch you have and how it is configured can be the difference between calls that sound great and calls that are a daily source of frustration.

## What a switch does

A switch is a device that connects all the wired devices on your network. Every desk phone, computer, printer, access point, and server that has an Ethernet cable plugs into a port on the switch. The switch's job is to move data between those ports.

When your phone sends a voice packet destined for the router (and ultimately, the internet), the switch receives the packet on the port where your phone is connected, reads the destination address in the packet header, looks up which port the router is connected to, and forwards the packet there. This happens for every single packet on your network, millions of times per second in a busy office.

A modern gigabit switch can do this at wire speed, meaning it forwards packets as fast as they arrive with no meaningful delay. The processing time is measured in microseconds. For a single packet, you would never notice the switch is even there.

The issues arise when you start asking the switch to do more than just forward packets, or when the switch is not capable of doing the things your network needs.

## Unmanaged switches

An unmanaged switch is the simplest type. You take it out of the box, plug in power, plug in Ethernet cables, and it works. There is no login screen, no configuration interface, no settings to change. It learns which devices are on which ports by watching the traffic, and it forwards packets based on destination addresses. That is all it does.

### When unmanaged works fine

For a small office with five or six people, a basic internet connection, and no VoIP phones, an unmanaged switch is perfectly adequate. It costs $30 to $100, it works immediately, and there is nothing to misconfigure because there is nothing to configure.

If your VoIP situation is simple, say three or four phones in a quiet office where the internet connection is never heavily loaded, an unmanaged switch will probably work fine for that too. The voice traffic is so light and the network is so uncongested that the lack of prioritization does not matter. There is no line to wait in because nobody else is in line.

### When unmanaged falls short

The problems start as the office grows. Here is what an unmanaged switch cannot do.

**No prioritization you can rely on.** To be precise, "managed versus unmanaged" is a distinction of control and visibility, not of what the forwarding silicon can do. Some unmanaged switches are built on chips that quietly honor 802.1p priority tags with multiple hardware queues. But the spec sheet rarely says so, you cannot configure it, and you cannot see counters that prove it is happening. In practice you have to assume the worst case: every packet gets equal treatment. A voice packet carrying part of an active phone conversation is handled the same as a packet from a Windows update downloading in the background, and when the switch's buffers fill up during a traffic burst, it drops packets without any consideration for what they contain. If it drops a voice packet, you hear a [glitch or gap in the audio](/blog/choppy-robotic-audio). If it drops a file transfer packet, the file transfer retransmits automatically and nobody notices.

**No VLANs.** An unmanaged switch puts all devices on one flat network. Your phones, computers, printers, security cameras, and guest devices all share the same broadcast domain. Every broadcast packet (and there are more of these than you might think) is sent to every device on every port. In a network with 30 or 40 devices, broadcast traffic can consume a meaningful amount of bandwidth and processing time on every connected device.

**No monitoring.** You cannot see traffic levels per port, error counts, or utilization statistics. When something is wrong, you have no diagnostic tools beyond unplugging cables and seeing what changes. This makes troubleshooting slow and frustrating, especially for intermittent problems.

**No PoE.** Most unmanaged switches do not provide Power over Ethernet. This means every VoIP phone needs its own power adapter plugged into a wall outlet, which adds cost, clutter, and another point of failure. (There are some unmanaged PoE switches, but they are essentially managed switches without the management interface, and the cost difference starts to close the gap.)

### The daisy chain problem

One of the most common network mistakes in growing offices is daisy-chaining unmanaged switches. The original 8-port switch filled up, so someone bought another 8-port switch and plugged it into the first one. Then a third. Sometimes a fourth.

Each switch in the chain adds a small amount of processing delay. More importantly, the link between the two switches becomes a bottleneck. All traffic from devices on the second switch that needs to reach the router has to pass through that single link to the first switch. If eight devices on the second switch are all active, they are sharing one gigabit link where they used to each have their own.

Daisy-chaining also makes troubleshooting nearly impossible. When calls on one desk sound bad, is it the phone, the cable, the second switch, the link between the switches, the first switch, or the router? With no monitoring or diagnostics on any of the switches, you are guessing.

The fix is almost always to replace the chain with a single managed switch that has enough ports for everything. We will get to what managed switches offer in a moment, but even replacing daisy-chained unmanaged switches with a single, larger unmanaged switch is an improvement.

## Managed switches

A managed switch does everything an unmanaged switch does, plus a set of features that give you control over how traffic is handled, monitored, and organized. You access these features through a web interface, a command line, or a management application, depending on the manufacturer.

The word "managed" might sound like it means "complicated." It does not have to be. Many modern managed switches have setup wizards and default configurations that handle the most common scenarios with minimal effort. And the features that matter most for VoIP are straightforward to enable.

### Quality of Service

This is the big one. A managed switch can read the priority markings on packets and treat them accordingly, and lets you verify that it is doing so. When your VoIP phone sends a voice packet marked with [DSCP 46 (Expedited Forwarding)](/blog/quality-of-service-explained), the marking RFC 4594 recommends for telephony media, the managed switch recognizes it and puts the packet in a high-priority queue. When the switch needs to choose which packet to forward next, voice packets go first.

On an unmanaged switch you get whatever behavior the silicon happens to have, with no way to configure or confirm it. If it treats everything as one first-come, first-served line, that voice packet sits behind whatever else is waiting, which could be a multi-gigabyte file copy between two computers. The file copy does not care about an extra millisecond of delay. The voice call does.

Quality of Service on the switch matters most when the internal network is busy. If you have people transferring large files between departments, running backups to a local server, or doing video editing that involves moving large files across the network, voice traffic benefits enormously from switch-level QoS.

Even if the internal network is not usually busy, QoS on the switch provides insurance. It protects voice quality during the unexpected moments when a software update deploys to 20 machines simultaneously, or someone accidentally starts a massive file copy during business hours.

### VLANs

VLANs (virtual local area networks) let you divide one physical switch into multiple logical networks. You can put voice devices on one VLAN and data devices on another, even though they are plugged into the same physical switch.

This is such an important concept that we dedicate the [entire next post](/blog/office-network-vlans) to it. The short version is that VLANs give you traffic isolation (voice and data do not interfere with each other), easier troubleshooting (you can immediately see whether a problem is on the voice side or the data side), and a foundation for effective QoS enforcement.

### PoE (Power over Ethernet)

Power over Ethernet is one of those features that, once you have it, you wonder how you ever lived without it.

A PoE-capable switch delivers electrical power to connected devices through the same Ethernet cable that carries data. For VoIP phones, this means the phone gets its data connection and its power from a single cable. No separate power adapter, no extra wall outlet needed, no additional cable to manage.

Beyond the convenience, PoE provides a meaningful operational benefit. When you connect the switch to an uninterruptible power supply (UPS), your phones stay powered during a power outage, just like old analog phones used to work during outages because the phone company powered them through the phone line. This can be important for businesses that need phone access during emergencies.

PoE comes in several standards. The original PoE (802.3af) provides up to 15.4 watts per port, which is enough for most desk phones. PoE+ (802.3at) provides up to 30 watts, sufficient for phones with color screens and sidecar modules. PoE++ (802.3bt) goes up to 60 or 90 watts depending on the type, which can power wireless access points and other higher-draw devices.

When shopping for a PoE switch, pay attention to the total power budget, not just the per-port rating. A 24-port PoE switch with a 200-watt total budget can only provide about 8 watts per port if all ports are drawing power. That is fine for basic phones but tight if you are also powering access points. Make sure the total power budget covers your actual deployment.

### Port monitoring and diagnostics

When something goes wrong on your network, a managed switch gives you tools to investigate. You can see how much traffic is flowing through each port, whether any ports are experiencing errors, which ports are at or near capacity, and what devices are connected where.

This matters enormously for VoIP troubleshooting. If a specific phone is having quality problems, you can look at the switch port it is connected to and see whether there are CRC errors (which suggest a cable problem), high utilization (which suggests congestion), or packet drops (which suggest a buffer overflow). On an unmanaged switch, you have no access to this information.

Some managed switches also support port mirroring, which lets you copy all traffic from one port to another for analysis. This is invaluable for advanced [VoIP troubleshooting](/blog/diagnosing-voip-problems) when you need to capture and examine actual packets.

## The passthrough port on VoIP phones

Most VoIP desk phones have two Ethernet ports on the back. One connects upstream to the wall jack (and ultimately to the switch). The other connects to the user's computer.

This design exists so that each desk only needs one cable run from the network closet. The phone sits in the middle, acting as a tiny, two-port switch. Traffic from the computer passes through the phone to reach the network, and traffic for the computer passes through the phone on the way back.

This works well, and it is the standard deployment in most offices. But there are a few things to understand about it.

### VLAN tagging

When VLANs are in use (and we will cover this in detail in the [next post](/blog/office-network-vlans)), the phone typically tags its own voice traffic with the voice VLAN ID and passes the computer's traffic through untagged (or tagged with the data VLAN). The phone learns which VLAN to use from the switch via LLDP-MED or CDP, which are discovery protocols that let the switch tell the phone "your voice traffic should be on VLAN 100."

This is elegant and mostly automatic, but it depends on the switch being properly configured to advertise the voice VLAN on that port. If the switch is unmanaged, there is no way to configure this, and VLAN separation is not possible.

### Traffic prioritization through the phone

The phone's internal mini-switch typically prioritizes its own voice traffic over the passthrough computer traffic. This means that even if the computer is downloading a large file, the phone's voice packets get sent first through the upstream link to the wall jack.

However, this only prioritizes traffic on the single link between the phone and the wall jack. Once the traffic reaches the main switch, prioritization depends on the switch's QoS configuration. If the switch is unmanaged, the prioritization the phone applied is effectively lost.

### The passthrough port limitation

The passthrough port on most phones is limited to 100 megabits per second, even if the phone's network port supports gigabit. This was a common limitation on older phones and persists on some current models. If the computer user needs gigabit speeds (for large file transfers, for example), they may need a second cable run to the desk instead of passing through the phone.

Newer phones increasingly support gigabit on both ports, so this is becoming less of an issue. Check the specs of your specific phone model if it matters for your environment.

## What to look for when buying a switch

If you are in the market for a switch, whether to replace an aging unmanaged switch or to upgrade as part of improving VoIP quality, here are the features that matter.

### Port count with room to grow

Count every device that needs a wired connection: phones, computers, printers, access points, cameras, and anything else. Then add 20 to 30 percent for growth. Running out of ports leads to daisy-chaining, which is what you are trying to avoid.

Common sizes are 8, 16, 24, and 48 ports. For a 15-person office where each desk has a phone and a computer sharing a single cable run (using the phone's passthrough port), you need 15 ports for the phones plus ports for printers, access points, and the router uplink. A 24-port switch handles this with room to spare.

### Gigabit ports

Every port should be gigabit (1000BASE-T). 10/100 switches are obsolete for any new deployment. The price difference is negligible and gigabit ensures your switch is not a bottleneck for any device.

### PoE support

If you are deploying VoIP phones, PoE simplifies installation and provides power resilience. Make sure the total power budget covers your deployment with margin.

### VLAN support

Essential for separating voice and data traffic. Any managed switch supports VLANs, but verify that the switch supports 802.1Q VLAN tagging, which is the standard that makes voice VLAN tagging on phone passthrough ports work.

### QoS support

The switch should support DSCP-based QoS and priority queuing. Look for support for at least four queues (most managed switches offer this) so that voice, video, important data, and background traffic can be handled separately.

### LLDP-MED or CDP support

These protocols let the switch automatically tell phones which VLAN to use and how to tag their traffic. This makes phone deployment much simpler and more reliable than manually configuring each phone.

### Management interface

A web-based management interface is standard on modern managed switches and sufficient for most small and medium offices. If you have an IT team or managed service provider, they may prefer switches that support centralized management through a cloud controller or on-premises management platform.

## The cost question

The price gap between unmanaged and managed switches has narrowed significantly over the past several years. A basic 24-port unmanaged gigabit switch costs around $80 to $150. A 24-port managed gigabit switch with PoE costs $250 to $600, depending on the brand, the total PoE budget, and the feature set.

That difference is meaningful, but put it in context. A managed PoE switch that costs $400 and lasts five or more years provides VoIP-essential features for the cost of a few dollars per month per port. Compare that to the cost of ongoing call quality problems: lost productivity, frustrated employees, poor impressions on clients, and hours spent on troubleshooting without the diagnostic tools to find the answer.

For any office where VoIP quality matters, and that includes most offices since the phone system is how you talk to customers, a managed PoE switch is one of the best investments you can make in your infrastructure.

## When to replace your switch

If you recognize any of these situations, it is probably time.

**You are daisy-chaining switches.** Replace the chain with a single managed switch that has enough ports.

**Your phones need separate power adapters.** A PoE switch eliminates the adapters and gives you power resilience.

**You cannot see what is happening on your network.** A managed switch provides the visibility you need for effective troubleshooting.

**Your VoIP provider or IT support has recommended VLANs or QoS.** You need a managed switch to implement either.

**You are experiencing intermittent call quality problems and have ruled out the internet connection.** The [local network](/blog/your-local-network) is next on the list, and the switch is a critical piece of it.

**Your switch only supports 10/100 Mbps.** Gigabit is the sensible baseline for any new purchase, and an old 100-megabit switch throttles the links that aggregate traffic: the uplink to the router, trunks between switches, and anything serving a busy file server. Be clear about where the bottleneck actually is, though. A 100 Mbps access port is far more than a phone will ever use (a call is well under 100 kbps), so the phone itself is not the reason to upgrade. Utilization and oversubscription at uplinks, trunks and the WAN egress are.

If you suspect your switch is affecting call quality but are not sure, running a [VoIP quality test](/tools/voip-test) from a device on your network can help quantify the jitter, latency, and packet loss that your current setup is introducing.

## What comes next

Now that you understand what switches do and why managed switches matter for VoIP, the next post covers one of the most important features a managed switch enables: VLANs. We will explain what VLANs are, why separating your voice and data traffic onto separate virtual networks is one of the best things you can do for call quality, and how the pieces fit together.

---

*This is Part 3 of the [Your Office Network](/blog?category=guides) series. [Part 4: VLANs: Giving Your Phones Their Own Lane](/blog/office-network-vlans) explains how to separate voice and data traffic for better performance and easier troubleshooting.*

---

### Part 4: VLANs: Giving Your Phones Their Own Lane

URL: https://voiptest.com/blog/office-network-vlans
Published: 2026-03-30
Tags: office-network, vlan, voice-vlan, network-segmentation, traffic-isolation

*Your Office Network: Part 4 of 10*

In the [previous post](/blog/office-network-switches), we covered why managed switches matter and mentioned VLANs several times as one of their most important features. Now we are going to explain what VLANs actually are, why they matter so much for VoIP, and how to think about implementing them in your office.

This is one of those topics that sounds intimidating but is built on a simple idea. Once you understand the concept, everything else falls into place.

## The highway analogy

Imagine a two-lane road connecting two parts of town. Cars, trucks, bicycles, and pedestrians all share the same road. Most of the time, traffic flows fine. But during rush hour, everything slows down. A truck making a wide turn blocks both lanes. A cyclist weaving through traffic forces cars to brake. A pedestrian crossing at the wrong time causes a chain reaction of slowdowns.

Now imagine that same road is widened into a highway with dedicated lanes. Cars get their own lanes. Trucks get their own lane. Bicycles get a separated bike path. Pedestrians get a sidewalk. Each type of traffic moves at its own pace without interfering with the others. A slow truck does not hold up cars. A cyclist does not cause cars to swerve. Everyone gets where they are going more predictably.

That is what a VLAN does for your network. It takes one physical network, the shared road, and paints separate logical lanes for different types of traffic. Your voice traffic gets its own lane. Your data traffic gets its own lane. They share the same physical cables and switches, but they stay cleanly separated. Keep one thing about the analogy in mind as we go: painting the lane is not the same as giving anyone right-of-way. That second job belongs to QoS, and the two work together.

## What a VLAN actually is

VLAN stands for Virtual Local Area Network. The "virtual" part is the key word. Without VLANs, every device plugged into a switch is on the same network. They can all see each other, they all share the same broadcast domain, and they all compete for the same resources.

A VLAN creates a logical division within that physical network. Devices on VLAN 100 can only communicate directly with other devices on VLAN 100. Devices on VLAN 200 can only communicate directly with other devices on VLAN 200. Even though a phone on VLAN 100 and a computer on VLAN 200 might be plugged into adjacent ports on the same switch, they behave as if they are on completely separate networks.

This separation is enforced by the switch. When a device on VLAN 100 sends a broadcast packet (and there are a lot of these on any network), the switch only forwards it to other ports assigned to VLAN 100. Devices on VLAN 200 never see it. When a device on VLAN 100 sends a packet to a device on VLAN 200, the switch does not forward it directly. Instead, the packet has to go through a router, which can apply rules, prioritization, and filtering before allowing the communication.

The technology that makes this work is defined in the IEEE 802.1Q standard. It adds a small tag to each Ethernet frame that identifies which VLAN it belongs to. Switches read this tag and use it to make forwarding decisions. The tag is just four bytes, a tiny addition that is invisible to the end devices but gives the switch the information it needs to enforce the separation.

## Why VLANs matter for VoIP

There are three reasons VLANs improve VoIP quality, and each one is significant on its own.

### Performance isolation

This is the most immediate benefit. When voice and data traffic share the same network without VLANs, they share everything: bandwidth, switch buffers, broadcast domains, and processing capacity. A heavy data event on the network affects voice traffic directly.

Consider what happens when someone in the office starts copying a large directory of files from one computer to a shared server. That file copy generates a burst of traffic that can temporarily saturate the link between the switch and the router. On a flat network, voice packets from active phone calls are sitting in the same queue as those file transfer packets, waiting their turn. The file transfer does not care about an extra 50 milliseconds of delay. The voice call absolutely does. That 50 milliseconds is the difference between clear audio and [choppy, robotic sound](/blog/choppy-robotic-audio).

Here is the honest version of what a VLAN does about that: on its own, nothing. A VLAN is a Layer 2 segmentation and policy boundary, not a scheduling mechanism: creating one does not make the switch build a separate queue per VLAN or reserve bandwidth. Voice packets on VLAN 100 still cross the same congested uplink. What the VLAN provides is a clean, unambiguous way to classify voice traffic, so that [Quality of Service](/blog/quality-of-service-explained) settings (which we cover in the [next post](/blog/office-network-qos)) can map it into a priority queue at each bottleneck. The segmentation and the scheduling are two separate jobs; combined, the file transfer still happens, but it does not crowd out voice traffic.

Broadcast traffic is the other performance concern. On a flat network, every broadcast packet from every device is sent to every other device. ARP requests, DHCP discoveries, NetBIOS announcements, and various other housekeeping traffic all generate broadcasts, and chatty protocols like mDNS (which is technically multicast, not broadcast, but floods a flat Layer 2 network in much the same way) add to the noise. In a network with 40 or 50 devices, this background traffic can consume a surprising amount of bandwidth and processing time.

With VLANs, broadcasts and link-local multicast are contained within their VLAN. Broadcasts from computers on the data VLAN never reach phones on the voice VLAN. Broadcasts from phones never reach computers. Each VLAN has a smaller, quieter broadcast domain, which means less background noise for every device. One caveat: if you rely on mDNS-based discovery (AirPlay, Chromecast, network printers), that discovery stops at the VLAN boundary too, so reaching those devices across VLANs requires a deliberate mDNS reflector or gateway policy on the router; it does not happen by accident.

### QoS enforcement

VLANs provide the foundation for effective Quality of Service. Without VLANs, QoS has to identify voice traffic by inspecting packet headers, looking at source and destination addresses, or relying on the devices to mark their own packets correctly. This works, but it is fragile. A misconfigured device, a new application that happens to use the same port numbers as VoIP, or a QoS configuration error can cause the wrong traffic to get priority treatment.

With VLANs, QoS classification becomes far simpler and more reliable. Everything on the voice VLAN came from a phone, so there is no guessing about which devices' markings to trust. One nuance worth keeping straight: "came from a phone" is not the same as "is voice audio." The voice VLAN carries the phones' RTP media, but also their SIP signaling, DHCP, DNS, provisioning, NTP and management traffic. Good QoS policy uses the VLAN to scope trust, then prioritizes the actual media, the packets the phones mark EF (DSCP 46), the telephony class in RFC 4594, rather than strict-prioritizing every byte on the VLAN.

This also makes bandwidth guarantees practical. The reservation itself is a QoS scheduler configuration on the uplink, not something the VLAN does, but the VLAN gives the scheduler a trustworthy classification to reserve against, ensuring that voice always has enough capacity regardless of what the data VLAN is doing. Try doing that on a flat network where voice and data are intermixed, and you will quickly run into the limits of packet-level classification.

### Troubleshooting simplicity

When call quality problems occur, the first question is always: where is the problem? On a flat network, the answer could be anywhere. Any device, any traffic pattern, any misconfiguration on any part of the network could be affecting voice.

With VLANs, you can immediately narrow the scope. Is the voice VLAN healthy? Check the traffic statistics on the voice VLAN ports. Are there errors, drops, or high utilization on the voice VLAN? If the voice VLAN looks clean, the problem is probably not local; it is upstream on the router, the [internet connection](/blog/isp-foundation), or the VoIP provider's side.

If the voice VLAN does show problems, you know exactly where to look. You do not have to sort through data traffic to find the voice traffic. You do not have to wonder whether that large file transfer or backup job is affecting calls. The voice VLAN gives you a clear, isolated view of your voice traffic.

For anyone who has spent hours trying to [diagnose VoIP problems](/blog/diagnosing-voip-problems) on a flat network where everything is intermixed, the troubleshooting clarity that VLANs provide is worth the setup effort by itself. Running a [VoIP quality test](/tools/voip-test) before and after implementing VLANs is one of the clearest ways to measure the improvement.

## How VLANs work with phones

The mechanics of how VoIP phones use VLANs are clever and mostly automatic, which is good because it means you do not have to manually configure each phone.

### Discovery protocols: LLDP-MED and CDP

When a VoIP phone boots up and connects to a managed switch, it needs to find out which VLAN to use for its voice traffic. It does this through a discovery protocol, most commonly LLDP-MED (Link Layer Discovery Protocol - Media Endpoint Discovery) or CDP (Cisco Discovery Protocol).

Here is how it works. The switch is configured to know that a particular VLAN (say, VLAN 100) is the voice VLAN. When the phone connects, the switch sends a message through the discovery protocol that says, essentially, "if you are a phone, put your voice traffic on VLAN 100." The phone receives this message, acknowledges it, and starts tagging its voice packets with a VLAN 100 tag.

This is automatic. You configure the voice VLAN on the switch once, and every phone that plugs in learns the correct VLAN automatically. No manual configuration on each phone. No static VLAN assignments that break when you move a phone to a different port.

### Tagged and untagged traffic

Remember from the [previous post](/blog/office-network-switches) that most VoIP phones have two Ethernet ports: one for the network uplink and one for the computer passthrough. The phone sits between the wall jack and the computer, acting as a tiny switch.

When VLANs are in use, the phone does something specific with traffic tagging. Its own voice traffic gets tagged with the voice VLAN ID (VLAN 100 in our example). The computer's traffic passes through the phone untagged, which means the switch treats it as belonging to the default or native VLAN, typically the data VLAN (say, VLAN 200).

The result is that a single cable run from the closet to the desk carries both voice traffic (tagged with VLAN 100) and data traffic (untagged or tagged with VLAN 200), and the switch knows how to separate them. This is why the 802.1Q standard and voice VLAN support on the switch are essential. Without them, this clean separation on a single cable is not possible.

The switch port that the phone connects to is configured as a "trunk" port or, in some vendors' terminology, a "voice and data" port. It is told to expect tagged traffic on the voice VLAN and untagged traffic on the data VLAN. This configuration is standard on any managed switch that supports VoIP deployment.

## Setting up a voice VLAN

The specific steps vary by switch and router manufacturer, but the general process is the same everywhere. Here is what it looks like at a conceptual level. This is not a step-by-step configuration guide (those are vendor-specific and would fill a separate post for each brand), but it gives you a clear picture of what needs to happen.

### Step 1: Create the VLAN

On your managed switch, create a new VLAN and give it an ID. The convention that most VoIP professionals use is VLAN 100 for voice, though the specific number does not matter technically. What matters is that you pick a number and use it consistently.

Give the VLAN a descriptive name like "Voice" so that anyone looking at the configuration later knows what it is for.

### Step 2: Configure switch ports

For each port where a VoIP phone is connected, configure the port to support both the voice VLAN (tagged) and the data VLAN (untagged). Enable LLDP-MED or CDP on these ports so the switch can automatically tell phones which VLAN to use.

For ports where only computers or other data devices are connected (no phone), configure those ports as simple access ports on the data VLAN.

For the port that connects the switch to the router (the uplink), configure it as a trunk port that carries both VLANs. The router needs to see traffic from both VLANs so it can route between them and to the internet.

### Step 3: Configure the router

The router needs to know about both VLANs and be able to route traffic between them and to the internet. This is called inter-VLAN routing. On most business routers, you create a sub-interface or virtual interface for each VLAN on the port that connects to the switch.

Each VLAN gets its own subnet. For example, the voice VLAN might use 10.10.100.0/24 and the data VLAN might use 10.10.200.0/24. The router serves as the gateway for both subnets.

### Step 4: Set up DHCP

Each VLAN needs its own DHCP scope so that devices get IP addresses on the correct subnet. Phones on the voice VLAN get addresses in the 10.10.100.x range. Computers on the data VLAN get addresses in the 10.10.200.x range.

The DHCP server can be on the router itself (common in small offices) or a separate server. If it is a separate server, the router needs to be configured as a DHCP relay agent so that DHCP requests from each VLAN reach the DHCP server.

The DHCP scope for the voice VLAN can also deliver phone-specific settings like the address of the VoIP server or phone provisioning URL, depending on your phone system.

### Step 5: Apply QoS

With VLANs in place, [QoS configuration](/blog/quality-of-service-explained) becomes straightforward: trust the markings coming from the voice VLAN, because everything on it came from a phone. On the switch and on the router's outbound interface (where your network meets the internet), honor the DSCP markings the phones apply, EF (DSCP 46) on media, per RFC 4594, and map them to the appropriate priority queue. Prioritize the marked media rather than the VLAN wholesale, since the voice VLAN also carries signaling, provisioning and management traffic that does not need strict priority.

We cover QoS in much more detail in [Part 5](/blog/office-network-qos) of this series.

## IP addressing with VLANs

When you create VLANs, each VLAN needs its own IP subnet. This is a fundamental requirement because VLANs are, from a networking perspective, separate networks.

A common addressing scheme looks like this:

- **Data VLAN (VLAN 200):** 10.10.200.0/24, gateway 10.10.200.1
- **Voice VLAN (VLAN 100):** 10.10.100.0/24, gateway 10.10.100.1

The /24 subnet gives you 254 usable addresses in each VLAN, which is more than enough for most small and medium offices.

The choice of 10.x.x.x addresses is convention, not requirement. You could use 192.168.x.x or 172.16.x.x addresses instead. The important thing is that the voice and data VLANs use different subnets so the router can tell them apart and route between them correctly.

Having separate subnets also means you can apply firewall rules between VLANs if needed. For example, you might allow phones on the voice VLAN to reach the internet but prevent computers on the data VLAN from directly accessing the phones. This is a secondary security benefit of VLANs that is worth noting even though it is not the primary reason for implementing them in a VoIP context.

## When not to bother

VLANs add a layer of complexity to your network. For very small offices, that complexity may not be justified.

If you have three to five people, a few phones, a simple [internet connection](/blog/isp-foundation), and network traffic that is light enough that congestion never occurs, VLANs are probably overkill. The performance isolation they provide solves a problem you do not have. The troubleshooting benefits are less important when the network is small enough to understand at a glance.

In a three-person office, if calls sound bad, the list of possible causes is short and easy to work through without VLAN-level isolation helping you narrow it down. The [diagnostic approach](/blog/diagnosing-voip-problems) in a small environment is straightforward enough without the additional segmentation.

An unmanaged switch, a decent router, and wired connections for all phones (as we covered in [Part 2](/blog/office-network-wired-vs-wifi)) will handle VoIP just fine in a very small office. Spend the time and money on good cabling and a solid internet connection instead.

## When to implement

The calculation changes as the office grows. Here are the signals that it is time.

**Eight to ten or more devices on the network.** At this point, broadcast traffic starts to become noticeable, and the chances of data traffic bursts affecting voice traffic increase. VLAN separation starts providing real performance benefits.

**You are experiencing intermittent call quality problems.** If calls sound fine most of the time but degrade during periods of heavy network use (large file transfers, cloud backups, video calls), VLAN separation combined with QoS is likely the fix.

**You are deploying a new phone system.** If you are setting up VoIP for the first time or migrating to a new system, implementing VLANs during the initial deployment is far easier than retrofitting them later. Most VoIP providers and installers will recommend or even require VLANs as part of a professional installation.

**Your IT provider or VoIP provider recommends it.** If the people managing your technology are asking for VLANs, listen to them. They are seeing the symptoms that indicate the need.

**You need to meet compliance or security requirements.** Some industries require network segmentation for compliance purposes. VLANs provide a documented, auditable separation between network segments.

**You have a mix of device types and trust levels.** If your network includes guest Wi-Fi, security cameras, IoT devices, or other equipment that should not have unrestricted access to your business network, VLANs provide the segmentation you need. You would typically put these devices on their own VLANs separate from both voice and data.

## Common VLAN mistakes

A few pitfalls to watch for during implementation.

**Not configuring the router for inter-VLAN routing.** If you create VLANs on the switch but do not set up the corresponding sub-interfaces on the router, devices on different VLANs cannot communicate with each other at all, and phones on the voice VLAN cannot reach the internet.

**Forgetting the DHCP scope.** If you create a voice VLAN but do not create a DHCP scope for it, phones will not get IP addresses and will not work. This is a common "everything was working and now nothing works" mistake during VLAN implementation.

**Not enabling the discovery protocol.** If LLDP-MED or CDP is not enabled on the switch ports, phones will not learn which VLAN to use and will default to the data VLAN (or no VLAN at all). Calls may still work, but without the isolation and QoS benefits that the VLAN was supposed to provide.

**Inconsistent VLAN IDs.** If you have multiple switches, the voice VLAN ID must be the same on all of them. VLAN 100 on switch A and VLAN 200 on switch B for the same purpose will cause confusion and routing problems.

**Overcomplicating it.** For most offices, two VLANs (voice and data) are sufficient. Adding VLANs for every department, every floor, and every device type creates management overhead that is not justified unless you have specific security or operational requirements.

## What comes next

With VLANs in place, your voice and data traffic are separated. But separation alone does not guarantee performance. The next post covers Quality of Service: how to tell your network that voice traffic gets priority treatment, where to apply it, and what it can and cannot do. QoS is the other half of the equation that makes VLANs truly effective for VoIP.

---

*This is Part 4 of the [Your Office Network](/blog?category=guides) series. [Part 5: QoS: Telling Your Network What Traffic Matters Most](/blog/office-network-qos) explains how to prioritize voice traffic on your local network.*

---

### Part 5: QoS: Telling Your Network What Traffic Matters Most

URL: https://voiptest.com/blog/office-network-qos
Published: 2026-03-31
Tags: office-network, qos, dscp, traffic-prioritization, bandwidth-management

*Your Office Network: Part 5 of 10*

We have covered the equipment in your [network closet](/blog/office-network-closet), why [wired beats Wi-Fi](/blog/office-network-wired-vs-wifi) for voice, what [switches](/blog/office-network-switches) do and why managed ones matter, and how [VLANs](/blog/office-network-vlans) give your phones their own lane on the network. All of those pieces set the stage for the topic that ties them together: Quality of Service.

Quality of Service, or QoS, is the mechanism that tells your network equipment which traffic matters most. Without it, your network treats every packet the same way, whether it is a voice packet from an active phone call or a chunk of a software update downloading in the background. With it, voice packets get to the front of the line.

If you have read our [fundamentals post on Quality of Service](/blog/quality-of-service-explained), you already have a solid understanding of the concepts. This post covers the same territory from a practical, office-network perspective: what you need to do, where you need to do it, and what you can realistically expect.

## The problem

Picture your router at 2 PM on a busy Tuesday. Twenty people are working. A few are on phone calls. Others are in video meetings. Someone started a cloud backup. A software deployment is pushing updates to a dozen computers. Three people are streaming training videos over lunch.

All of this traffic funnels through your router on its way to and from the internet. The router has one outbound connection: your [internet link](/blog/isp-foundation). If your internal network runs at gigabit speeds but your internet connection is 200 megabits per second, the router is a funnel. Everything has to squeeze through.

Without QoS, the router handles this traffic on a first-come, first-served basis. Every packet waits in the same queue. When the queue fills up because more traffic is arriving than the internet link can carry, the router starts dropping packets from the end of the queue. It does not know or care what those packets contain.

The software update does not care. It uses TCP, which detects the dropped packet and retransmits it automatically. The user never notices. The video meeting buffers for a moment and recovers. The cloud backup slows down slightly.

But the voice call cares. Voice uses UDP, which does not retransmit. A dropped voice packet is gone. The listener hears a gap, a click, or a moment of [choppy, robotic audio](/blog/choppy-robotic-audio). A few dropped packets in a row and the call becomes hard to follow. And unlike a video meeting that can buffer a little, voice is real-time. There is no buffer to absorb the delay. The packet either arrives on time or it is useless.

This is the problem QoS solves. Not by creating more bandwidth, but by ensuring that when bandwidth is scarce, the traffic that cannot tolerate delay gets served first.

## How QoS identifies voice traffic

Before the network can prioritize voice packets, it has to know which packets are voice. There are several ways to identify them, and in practice, most VoIP deployments use a combination.

### DSCP marking

DSCP stands for Differentiated Services Code Point. It is a 6-bit field in the header of every IP packet that can carry a value indicating what type of traffic the packet contains and how it should be treated.

The standard DSCP value for voice media is 46, which maps to a forwarding behavior called Expedited Forwarding (EF), the marking RFC 4594 recommends for telephony media. (RFC 4594 recommends CS5, decimal 40, for the accompanying call signaling; some enterprise and Cisco deployments use CS3 for signaling instead, which is a common convention rather than the RFC's recommendation. Whichever you use, document it and apply it consistently.) When a router or switch sees a packet marked with DSCP 46, it knows to treat it as real-time voice that needs immediate forwarding with minimal delay and minimal loss.

Here is the important part: most VoIP phones mark their packets with DSCP 46 by default, right out of the box. You do not need to configure this on the phones. They do it automatically. The phones are already telling the network "this is voice traffic, please prioritize me." The question is whether your network equipment is listening.

On an unmanaged switch, the answer is no. Unmanaged switches do not read DSCP markings. They forward every packet the same way regardless of what the DSCP field says. The phone is asking for priority, but nobody is home to hear the request.

On a managed switch with QoS enabled, the switch reads the DSCP value, recognizes that 46 means high priority, and puts the packet in a priority queue. On a properly configured router, the same thing happens at the outbound interface where traffic leaves your network.

### VLAN membership

If you have implemented [VLANs](/blog/office-network-vlans) as we described in the previous post, the network has another useful signal: VLAN membership. Everything on the voice VLAN came from a phone, so the VLAN tells you whose markings to trust. Be careful not to over-read that, though. A voice VLAN carries more than RTP audio: SIP signaling, DHCP, DNS, provisioning downloads, NTP, HTTPS management sessions, and sometimes a PC daisy-chained behind the phone. Strict-prioritizing the entire VLAN would put a phone's firmware download in the same queue as live audio. The better pattern is to use the VLAN to scope trust, then prioritize the packets the phones mark EF (the bearer media) and give signaling and management their own, lower classes.

This is one of the reasons VLANs and QoS work so well together. VLANs provide trustworthy classification boundaries, and QoS provides the action (give the media priority).

### 802.1p priority

When a packet is tagged with a VLAN ID (using 802.1Q, as we discussed in the VLAN post), the tag includes a 3-bit priority field called 802.1p or CoS (Class of Service). This field can carry a value from 0 to 7, with higher numbers indicating higher priority. Voice traffic is typically assigned a value of 5.

The 802.1p priority works at Layer 2 (the switch level), while DSCP works at Layer 3 (the IP level). In a well-configured network, these two systems are aligned: a voice packet tagged with 802.1p priority 5 on the VLAN also carries a DSCP value of 46 in its IP header. The switch uses the 802.1p value for its internal queuing decisions, and the router uses the DSCP value for its outbound queuing decisions.

Most managed switches can be configured to map between these two systems automatically. When a packet arrives with DSCP 46, the switch assigns it 802.1p priority 5 for internal handling, and vice versa.

## The three things that need to happen

Making QoS work for VoIP requires three things to be in place. If any one of them is missing, the chain is broken and voice packets do not get the priority treatment they need.

### 1. Phones mark their packets

As mentioned, most VoIP phones do this by default. They stamp every voice packet with DSCP 46. You should verify this is happening rather than just assuming it, especially if your phones are older or if your VoIP provider uses non-standard configurations.

If you are using softphones (VoIP applications on computers) rather than hardware desk phones, the situation is slightly more complex. Some operating systems restrict applications from setting DSCP values on packets unless the application has elevated permissions. Windows, in particular, has a Group Policy setting that controls whether applications can set DSCP markings. If your softphone packets are leaving the computer with DSCP 0 (best effort, the default), they will not receive priority treatment regardless of how well the rest of the network is configured.

Your VoIP provider or IT team can verify that phones are marking correctly by capturing a few packets and inspecting the DSCP field.

### 2. Switches honor the markings

This is where managed switches earn their keep. A managed switch with QoS enabled reads the DSCP value (or the 802.1p value if VLANs are in use) and places the packet in the appropriate internal queue.

Most managed switches support at least four priority queues, and some support eight. The typical mapping puts voice (DSCP 46) in the highest-priority queue, video (DSCP 34) in the next, important data in the third, and everything else in the default best-effort queue. The switch services the highest-priority queue first, ensuring that voice packets are forwarded with minimal internal delay.

On an unmanaged switch, this step is missing entirely. The switch has one queue, processes packets in order of arrival, and the DSCP markings are invisible to it. The phone's packets still carry the DSCP 46 marking, and if they reach a managed switch or router downstream, the marking will be honored there. But within the unmanaged switch, voice gets no special treatment.

This is why we emphasized in [Part 3](/blog/office-network-switches) that a managed switch is important for VoIP environments. The switch is not just a passive connector; it is an active participant in traffic prioritization.

### 3. The router prioritizes outbound traffic

This is where QoS has the most impact. The router's outbound interface, where your internal network meets your internet connection, is the most common bottleneck in any office network. Your internal network runs at gigabit speeds. Your internet connection is probably 100 to 500 megabits per second, maybe faster, maybe slower. Every packet leaving your network has to pass through this bottleneck.

When more traffic is trying to leave than the internet link can carry, the router has to decide what goes first and what waits. Without QoS, it is first come, first served. With QoS, the router checks each packet's DSCP marking and places it in the appropriate outbound queue. Voice packets (DSCP 46) go into a strict priority queue that is serviced first. Everything else goes into lower-priority queues that are serviced when the priority queue is empty.

The result: during periods of congestion, voice packets experience near-zero additional delay at the router while file transfers, backups, and updates absorb the wait. The file transfer takes a fraction of a second longer. The voice call stays clear. This is almost always the correct trade-off.

The router is also where you set the bandwidth cap for the priority queue. This is an important safety measure. If you leave the priority queue uncapped and something misconfigured floods it with traffic (marked as DSCP 46 but not actually voice), it can starve all other traffic on the network. Size the cap from your own numbers, not a percentage rule of thumb: measure or estimate your peak simultaneous calls, multiply by the per-call bandwidth of your codec including packet overhead (a G.711 call at a 20 ms packet interval is roughly 87 kbps per direction on Ethernet; the exact figure shifts with headers and encapsulation), and add a safety margin. This is the same measured-concurrency approach Cisco's collaboration bandwidth management guidance takes; a flat "reserve 10 to 20 percent of upload" prescription reserves too much on a big pipe and too little on a small one.

For example, if you have a 100 Mbps upload connection and expect a maximum of 20 simultaneous calls at roughly 100 kbps each (87 kbps plus margin), that is about 2 Mbps of voice traffic. You might set the priority queue cap at 5 Mbps to provide generous headroom while ensuring that 95 Mbps remains available for everything else.

## QoS on the switch versus the router

People sometimes ask whether they need QoS on both the switch and the router, or if one is enough.

The short answer: the router is more important, but having both is better.

**QoS on the router** protects voice traffic at the most critical bottleneck, the internet connection. This is where congestion is most likely to occur because the internet link is slower than the internal network. If you could only configure QoS in one place, the router is the place.

**QoS on the switch** protects voice traffic within the internal network. This matters when internal traffic is heavy: large file transfers between computers, backups to a local server, multicast traffic, or high-volume data between departments. If internal traffic never creates congestion, switch-level QoS is less critical. But if internal traffic does occasionally spike, switch-level QoS prevents those spikes from affecting voice.

In practice, if you have invested in a managed switch (which you should, per [Part 3](/blog/office-network-switches)), enabling QoS on it is straightforward and there is no reason not to do it. Belt and suspenders.

## What QoS does not do

This is important to understand so you have realistic expectations.

### It cannot create bandwidth

QoS decides which traffic gets priority when there is not enough bandwidth for everyone. It does not make your internet connection faster. If your 50 Mbps connection is consistently running at 50 Mbps because your actual usage requires that much, QoS can prioritize voice within that 50 Mbps, but it cannot add a 51st megabit.

If your total traffic demand routinely exceeds your internet capacity, you need a faster connection. QoS buys you time during temporary bursts, but it cannot compensate for a connection that is fundamentally undersized. If you are evaluating whether your [ISP connection](/blog/isp-foundation) is adequate, QoS should be part of the conversation but not a substitute for adequate bandwidth.

### It only works on equipment you control

Once your voice packets leave your router and enter your ISP's network, your QoS settings no longer apply. DSCP is only a marking, and each network domain along the path decides for itself what to do with it: internet providers commonly ignore it, re-mark it at their edge, or strip it entirely. You should assume your markings carry no weight past your own router unless you have a contract that says otherwise. ISPs have little reason to honor priority markings set by their customers. If they did, every customer would mark all their traffic as high priority and the system would collapse.

This means QoS protects your voice traffic from congestion within your own network and at your router's outbound interface. It does nothing for the internet leg of the call. If the problem is [jitter](/blog/what-is-jitter-and-why-it-matters) or [packet loss](/blog/understanding-voip-packet-loss) occurring somewhere between your ISP and your VoIP provider, QoS on your end will not help. And that internet leg is where the majority of VoIP quality problems actually live.

[Dedicated internet access](/blog/dedicated-internet-access) helps not because of end-to-end QoS guarantees (those are rare and expensive even on DIA circuits), but because DIA provides consistent, uncontested bandwidth with SLA-backed performance commitments. The connection itself is better, which matters more than packet markings.

### It can mask the real problem

This is worth understanding clearly. If your network is congested enough that voice quality suffers without QoS, enabling QoS will keep calls clean by pushing the congestion onto other traffic. The calls sound better, but the congestion is still there. File transfers slow down. Cloud applications lag. And because the calls sound fine, nobody investigates.

Congestion is a signal. QoS suppresses that signal for voice while leaving the underlying problem in place. The better response to chronic congestion is to find out what is causing it and fix it -- whether that means upgrading the internet connection, scheduling backups outside business hours, or replacing a router that cannot handle the traffic volume. A network that is properly sized for its workload does not need QoS to keep calls clean most of the time.

The question of whether QoS earns its keep is about your bottlenecks, not your headcount. A one-person office on an asymmetric connection with a thin uplink can benefit enormously from smart queuing at the router, because a single cloud backup can saturate that uplink. Meanwhile a 200-person office with generous, uncontended bandwidth may never queue a packet and gains little from elaborate per-port policy. Diagnose where traffic actually queues -- usually the WAN egress -- and apply prioritization there, rather than assuming QoS is a big-network tool or a small-network irrelevance.

### It cannot fix broken equipment

QoS prioritizes traffic within a functioning network. If your switch is dropping packets because of a hardware defect, or your router is crashing under load, or your cables have bad terminations, QoS will not compensate. Fix the underlying hardware problems first, then apply QoS to optimize traffic handling.

### It requires correct configuration

Misconfigured QoS can make things worse than no QoS at all. If the wrong traffic is marked as high priority, it crowds out actual voice traffic. If the priority queue bandwidth cap is set too high, non-voice traffic starves. If DSCP markings are being stripped somewhere in the path, packets that should be prioritized are treated as best effort.

This is not a reason to avoid QoS. It is a reason to configure it carefully and verify it is working as intended. Running a [VoIP quality test](/tools/voip-test) during business hours, with QoS enabled, is the definitive way to confirm that voice traffic is actually getting the priority treatment you configured.

## Practical setup summary

Here is the sequence for implementing QoS in a typical small or medium office. The specific configuration steps depend on your equipment manufacturer, but the logic is the same everywhere.

**Step 1: Verify phone markings.** Confirm that your VoIP phones are marking voice packets with DSCP 46 (EF). Most do this by default. Softphones may need operating system configuration to allow DSCP marking.

**Step 2: Configure the switch.** On your managed switch, enable QoS and configure it to honor DSCP markings, but only from ports and devices you control. DSCP is just a marking; any device can write 46 into its packets, so trust the voice VLAN and phone ports, re-mark or police everything else at the edge, and rate-limit the EF class so a misbehaving device cannot flood the priority queue. Map DSCP 46 to the highest-priority queue. If you are using VLANs (which you should be, per [Part 4](/blog/office-network-vlans)), enable 802.1p and map voice traffic to priority 5.

**Step 3: Configure the router.** Create a QoS policy on your router's outbound (WAN) interface. Define a strict priority queue for DSCP 46 traffic. Set a bandwidth cap on the priority queue that covers your maximum expected call volume with margin. Place all other traffic in a default queue or create additional queues for video and important data if your router supports it.

**Step 4: Configure inbound QoS if supported.** Some routers support inbound QoS (also called ingress policing) to prioritize incoming voice packets over incoming data. This is less common and less impactful than outbound QoS because you have less control over the rate at which packets arrive from the internet. But if your equipment supports it, it provides additional protection for the download direction of voice calls.

**Step 5: Test during business hours.** Configure everything during a maintenance window, then test during a normal business day with typical traffic loads. Listen to calls during the [afternoon peak](/blog/afternoon-call-quality) when the network is busiest. Measure jitter and packet loss on voice traffic. If the numbers look good under load, your QoS is working.

**Step 6: Monitor and adjust.** QoS is not set-it-and-forget-it. As your office grows, as traffic patterns change, and as you add new applications and devices, the balance of traffic shifts. Review your QoS configuration periodically and adjust the bandwidth allocations if needed.

## The relationship between QoS and the rest of the series

QoS does not exist in isolation. It works best as part of a coherent network strategy.

[Wired connections](/blog/office-network-wired-vs-wifi) eliminate the jitter and loss that Wi-Fi introduces, giving QoS clean traffic to work with. If voice packets arrive at the switch already damaged by wireless interference, QoS can prioritize them but cannot un-damage them.

[Managed switches](/blog/office-network-switches) provide the hardware capability to read DSCP markings and enforce priority queuing internally. Without a managed switch, QoS only works at the router.

[VLANs](/blog/office-network-vlans) provide clean traffic classification so QoS knows exactly which traffic to prioritize. Without VLANs, QoS has to rely entirely on packet-level inspection, which is less reliable.

Together, wired connections, managed switches, VLANs, and QoS form a stack of protections that give your voice traffic the best possible chance of arriving intact, on time, every time. Any one of them helps. All of them together transform your [local network](/blog/your-local-network) from a variable that threatens call quality into a foundation that supports it.

## The bottom line

Quality of Service is not complicated in concept. It is the idea that not all network traffic is equally urgent, and the network should reflect that reality during moments of congestion. For VoIP, the implementation comes down to three things: phones mark their packets, switches honor the markings, and the router prioritizes outbound voice traffic at the internet bottleneck.

But keep two things in perspective. First, QoS only operates on your local network. It does nothing once packets hit your ISP. Most call quality problems originate on the internet side, where your QoS configuration has no effect. Second, if you are experiencing call quality problems that QoS would fix, that means your local network is congested, and you should understand why before you cover it up with traffic prioritization.

If you have been experiencing call quality that degrades in the afternoon, or calls that sound fine most of the time but occasionally fall apart, the first question to ask is not "do I have QoS configured?" It is "why is my network congested?" The answer might be an undersized internet connection, a backup job running during business hours, or a router that cannot keep up with the traffic load. Fix the root cause and QoS becomes insurance for unexpected spikes rather than a crutch for an undersized network.

## What comes next

The next post in the series moves beyond the core infrastructure and into the practical realities of managing an office network over time: firmware updates, monitoring, documentation, and the ongoing maintenance that keeps everything running smoothly after the initial setup.

---

*This is Part 5 of the [Your Office Network](/blog?category=guides) series. Part 6 covers ongoing network management and maintenance, the work that keeps your office network healthy after the initial setup.*

---

### Part 6: PoE: How Your Phones Get Power and What Happens When They Don't

URL: https://voiptest.com/blog/office-network-poe
Published: 2026-03-31
Tags: office-network, poe, power-over-ethernet, phone-power, switch-budget

*Your Office Network: Part 6 of 10*

If you have VoIP desk phones in your office, there is a good chance each one runs on a single Ethernet cable. No separate power adapter. No power strip under the desk. Just the one cable running from the phone to the wall jack, and from there back to a [switch](/blog/office-network-switches) in your [network closet](/blog/office-network-closet). That cable carries both the network data and the electrical power the phone needs to operate.

This is Power over Ethernet, universally called PoE, and it is one of those technologies that works so well when it is set up correctly that nobody thinks about it. The problems start when the setup is not quite right, or when the network grows past what the original equipment was designed to support.

## What PoE actually is

At its core, PoE is a way to deliver electrical power over the same copper Ethernet cable that carries network data. The [switch](/blog/office-network-switches) (or a separate device called a PoE injector) puts power onto the cable. The device at the other end, your phone, your wireless access point, your security camera, draws that power to operate.

The phone does not know or care that it is receiving power from the cable rather than a wall outlet. From the phone's perspective, it boots up, connects to the network, and works. The cable handles both jobs simultaneously.

This matters for office environments because it dramatically simplifies deployment. You do not need a power outlet at every desk where a phone sits. You do not need power adapters cluttering up desks. When you add a new phone, you just run a cable. When you move a phone, you just move the cable. The phone works wherever there is a network drop, because the network drop is also the power source.

It also matters for reliability in a way that is easy to overlook. If your network switches are connected to an uninterruptible power supply in the [network closet](/blog/office-network-closet), then every PoE phone in the building inherits that backup power automatically. When the power goes out, your phones stay on as long as the UPS battery holds. No separate battery backups at each desk. No phones going dark while the computers on their own UPS keep running.

## The PoE standards

Not all PoE is the same. The IEEE has defined several standards, and they differ primarily in how much power they can deliver to a device. Knowing which standard your equipment supports matters because it determines what devices you can power and how many of them.

### 802.3af (PoE): 15.4 watts

This is the original PoE standard, and it is sufficient for most VoIP desk phones. A typical desk phone draws somewhere between 5 and 13 watts, well within the 15.4 watts that 802.3af provides. If your phones are standard desk models (not large touchscreen phones, not conference room units), 802.3af is probably all you need on the phone side.

One important detail: the 15.4 watts is the power the switch (the PSE, in the standard's terms) puts onto the cable. The standard separately guarantees what the powered device receives after resistive loss in the cable: 12.95 watts, and that guarantee already assumes a full-length, standards-compliant 100 meter channel. For a desk phone drawing 6 to 10 watts, this is still plenty. But it is worth understanding that the number on the spec sheet is the sourced power, and the guaranteed delivered power is the smaller figure.

### 802.3at (PoE+): 30 watts

PoE+ roughly doubles the available power: 30 watts sourced at the switch port, with 25.5 watts guaranteed at the device after cable loss. This is what you need for devices that draw more than a basic desk phone: conference room phones with large displays and speaker arrays, wireless access points (especially modern WiFi 6 models), certain video phones, and IP cameras with pan-tilt-zoom motors.

If you are deploying wireless access points alongside your phones and powering them from the same switches, you almost certainly need switches that support 802.3at. A modern WiFi 6 access point can draw 15 to 25 watts, which exceeds what 802.3af can deliver.

### 802.3bt (PoE++): 60 to 90 watts

This is the most recent standard, and it provides significantly more power: 60 or 90 watts sourced at the port depending on the type. It gets there with a fundamental change in how the cable is used. 802.3af and 802.3at energize two of the cable's four wire pairs; 802.3bt energizes all four, which is how it pushes that much more power through the same copper. Devices that need this much include high-end video conferencing units, digital signage displays, and some specialized equipment. For a standard office phone deployment, 802.3bt is overkill. You are unlikely to need it unless you are powering something beyond phones and access points.

The reason to know about 802.3bt is not because you need it today, but so you are not confused when you see it on spec sheets. If a switch vendor is advertising PoE++ support, that is a feature aimed at specific use cases, not something that makes your desk phones work better.

### How the negotiation works

When a PoE device is plugged into a PoE switch port, the switch does not immediately blast full power down the cable. There is a negotiation process. The switch sends a low-voltage probe signal to detect whether the connected device is PoE-capable. If it is, the switch and the device agree on a power class, which tells the switch how much power the device needs. Only then does the switch deliver the appropriate amount of power.

This negotiation is why you can safely plug a non-PoE device into a PoE switch port. The switch probes the device, gets no PoE response, and simply does not deliver power. The port works as a normal Ethernet port. You will not damage a laptop or a printer by plugging it into a PoE switch.

## The PoE budget: the problem nobody plans for

Here is where most offices get caught. Every PoE switch has a total power budget. This is the maximum amount of electrical power the switch can deliver across all of its PoE ports combined. It is a fixed number determined by the switch's internal power supply, and it is almost always less than what you would get if every port delivered maximum power simultaneously.

A 24-port PoE switch might have a power budget of 370 watts. If every port is using 802.3af to power a phone drawing 15.4 watts at maximum, the theoretical demand is 24 times 15.4, which is 369.6 watts. That is cutting it extremely close. And if any of those devices draw more than the minimum, or if you plug in a few access points that need 20 watts each, the math stops working.

### What happens when the budget runs out

When a switch's PoE budget is fully allocated and you plug in one more device, the switch has to make a choice. Different switches handle this differently, and none of the options are good.

Some switches refuse to power the new device. The phone plugs in and simply does not boot. There is no error message on the phone because the phone never receives power. It sits there dark and silent. If you do not know about PoE budgets, this looks like a dead phone or a bad cable. You might spend an hour troubleshooting the cable, swapping ports, even replacing the phone, before someone thinks to check the switch's power budget.

Some switches use a priority system (Cisco's Catalyst PoE configuration guides, for example, document per-port priority and exactly this shedding behavior). When the budget is exceeded, the switch powers down the device on the lowest-priority port to free up power for the new device. This means a phone that was working perfectly fine suddenly reboots or goes dark, seemingly at random. In practice, "at random" means "when someone plugged a new device in on the other side of the office," which is not an obvious connection to make.

Some less sophisticated switches simply become unstable when overloaded. Phones reboot intermittently. Power delivery fluctuates. The symptoms look like a hardware problem with the switch itself, or like a network problem, or like the phones are defective. Diagnosing this without knowing about PoE budgets is genuinely difficult.

### Real-world budget math

The good news is that most phones do not draw their maximum rated power continuously. A typical Polycom, Yealink, or Cisco desk phone draws 5 to 10 watts in normal operation. So a 24-port switch with a 370-watt budget can comfortably power 24 phones with room to spare.

The math gets tighter when you mix device types. Say you have 20 phones drawing 8 watts each (160 watts), plus 4 wireless access points drawing 20 watts each (80 watts). Total: 240 watts out of a 370-watt budget. That is fine. But add a few more access points, or upgrade to access points that draw 25 watts, and you start approaching the limit.

The rule of thumb is to add up the expected power draw of all PoE devices you plan to connect, then add 20 to 30 percent headroom. If the result exceeds your switch's PoE budget, you need either a switch with a larger power supply, a second switch, or separate PoE injectors for some devices.

## PoE and cable quality

How PoE uses the cable's four wire pairs depends on the standard. 802.3af and 802.3at deliver power over two pairs: either superimposed on the data pairs or carried on the spare pairs, at the switch's discretion (the standards call these Alternative A and Alternative B). 802.3bt energizes all four pairs to reach its higher power levels. Standard Ethernet data at 100 megabits also only uses two of the four pairs, which is why some very old or very cheap cables that are missing wire pairs can still carry data at lower speeds.

This is exactly why cable quality matters more when PoE is in play. A cable with a missing or broken pair might carry 100 megabit data fine, and might even power a device from one switch, then fail on another switch that energizes the other pairset. A marginal crimp on one connector might pass a quick data test but deliver fluctuating power. Gigabit data needs all four pairs regardless, so on a modern network the practical rule is simple: every pair intact, properly terminated, or the cable is a liability for both data and power.

The minimum cable category for PoE is Cat5e. If your building has old Cat5 (not Cat5e) or, worse, Cat3 cabling from a legacy phone system, that cabling may not reliably support PoE. We cover cable categories and their implications in detail in the [next post](/blog/office-network-cabling).

### Cable length and power delivery

Ethernet cables have a maximum supported length of 100 meters (roughly 328 feet). This limit applies to both data and power, and the longer the cable, the more power is lost to resistance in the copper wire.

Here is the part worth getting right: the PoE standards already account for that loss. The guaranteed device-side figures (12.95 watts for 802.3af, 25.5 watts for 802.3at) assume a full 100 meter standards-compliant channel. A compliant cable run at maximum length is not a reason for PoE to fail. So when a phone at the end of a long run boots intermittently, reboots under load, or fails to power up, the length itself is not the culprit; something else is out of spec. The usual suspects: cable that does not actually meet its category rating, copper-clad aluminum "Cat5e," poor terminations, couplers in the path, high ambient temperature in bundled cable runs, a device and switch negotiating the wrong power class, or a switch whose total PoE budget is exhausted.

Some switches report the actual power being drawn by each port, which can help you identify devices that are close to their negotiated limit and confirm whether the problem is the channel or the budget.

## PoE injectors and midspan devices

Not every switch has PoE capability, and not every environment needs to replace an entire switch just to power a few devices. That is where PoE injectors come in.

A single-port PoE injector is a small box that sits between the switch and the device. The Ethernet cable from the switch plugs into one side, a cable to the phone plugs into the other side, and the injector adds power to the cable. It is a targeted solution for adding PoE to one or two devices on a non-PoE switch.

A midspan injector (sometimes called a PoE patch panel) does the same thing for multiple ports. It sits between a non-PoE switch and a patch panel, adding power to some or all of the cables passing through it. This lets you add PoE capability to an existing switch without replacing it.

Injectors and midspans work well as interim solutions or for small deployments. In larger environments, a proper PoE switch is simpler and more manageable because the switch handles both data and power through a single management interface.

## Planning your PoE deployment

If you are setting up a new network or expanding an existing one, a few minutes of PoE planning prevents hours of troubleshooting later.

### Step 1: Inventory your PoE devices

List every device that will draw power from the switch. This typically includes desk phones, conference phones, wireless access points, and possibly security cameras or other devices. For each one, find the power draw specification, usually in the device's datasheet.

### Step 2: Add up the power

Sum the power draw of all devices. Use the typical (not maximum) power draw if your documentation distinguishes between the two. Most phones list both, and the typical draw is significantly lower than the maximum.

### Step 3: Add headroom

Add 20 to 30 percent to your total. This covers fluctuations in device power draw, future additions, and the reality that devices occasionally spike above their typical draw during boot-up or firmware updates.

### Step 4: Match to switch capacity

Compare your total (with headroom) to the PoE budget of the switch you are considering. If it fits with room to spare, you are set. If it is close, consider a switch with a larger power supply or plan to split the devices across two switches.

### Step 5: Verify cable quality

Confirm that your cabling is Cat5e or better and that all four pairs are intact. If you have any doubt, test the cables. A cable that passes a data test but fails PoE testing has a problem with one or more wire pairs.

## PoE and VLANs

If you followed the series through [VLANs](/blog/office-network-vlans), you know that voice and data traffic should be on separate VLANs. PoE works seamlessly with VLANs. The power delivery is a physical-layer function that has nothing to do with VLAN tagging. A port can be configured for a voice VLAN, a data VLAN, or both, and PoE will deliver power regardless of the VLAN configuration.

This is worth mentioning because people sometimes wonder whether VLAN configuration affects PoE. It does not. The power negotiation happens before any network traffic flows.

## PoE and QoS

Similarly, [QoS configuration](/blog/office-network-qos) and PoE are independent. QoS handles how traffic is prioritized on the network. PoE handles how power is delivered over the cable. You configure them separately, and they do not interact. A phone receiving PoE power does not get any different QoS treatment because of that; QoS is determined by traffic markings and switch configuration, not by power delivery.

## Common PoE problems and what they look like

Here is a quick reference for the PoE issues you are most likely to encounter.

**Phone does not power on at all.** Check whether the switch port has PoE enabled (some switches have it disabled by default). Check the PoE budget, because the switch may be out of power. Check the cable: a broken pair can kill power delivery depending on which pairset the switch energizes, and 802.3bt needs all four pairs. Try a different port to isolate whether the issue is the port, the cable, or the device.

**Phone reboots randomly.** This can indicate a PoE budget that is marginally exceeded, causing the switch to cycle power on lower-priority ports. It can also indicate a cable problem where one pair has an intermittent connection, causing power delivery to fluctuate. Check the switch's PoE power usage and port priority settings.

**Phone boots but shows errors.** Some phones display a warning if they are receiving less power than they request. This usually means the switch is providing 802.3af when the phone prefers 802.3at, or the power class negotiation went wrong. If the run is long, suspect out-of-spec cable or bad terminations rather than length itself; a compliant 100 meter channel is within the standard's power budget.

**Some phones work, new phones will not boot.** Classic PoE budget exhaustion. The budget was fully allocated by existing devices, and there is no power left for additional ones. Check the switch's total PoE utilization.

**Phone works on one port but not another.** If the phone works when plugged into a different port on the same switch, the original port may have PoE disabled, or there may be a cable problem between the original port and the wall jack. If the phone works on a different switch entirely, the first switch may have a PoE budget or hardware issue.

## The connection to call quality

PoE problems do not directly cause poor [call quality](/blog/choppy-robotic-audio) in the way that network congestion or [jitter](/blog/what-is-jitter-and-why-it-matters) does. But they cause something arguably worse: complete phone outages. A phone that cannot get power is a phone that does not work at all. And intermittent PoE problems cause intermittent phone reboots, which drop active calls and make the phone temporarily unavailable.

In a troubleshooting scenario, PoE issues are easy to overlook because they look like other problems. A phone that reboots during a call looks like a firmware crash. A phone that will not boot looks like a hardware failure. Random reboots look like a network issue. Knowing that PoE budget exhaustion and cable quality can cause these symptoms saves you from chasing the wrong problem. If you are seeing intermittent phone issues and have ruled out PoE, running a [VoIP quality test](/tools/voip-test) can help determine whether the problem is power-related (phones dropping entirely) or network-related (degraded audio on calls that stay connected).

## What you should know about your own setup

If you have PoE phones, here are the questions worth answering:

1. What is the total PoE budget of each switch that powers devices?
2. How much of that budget is currently being used? (Most managed switches report this in their web interface.)
3. How many additional PoE devices could you add before hitting the budget?
4. Are your cable runs within reasonable length, and is the cabling Cat5e or better?
5. Are your switches connected to a UPS, giving your phones backup power?

If you cannot answer these questions, that is normal. Most people cannot. But now you know they are worth asking.

---

*This is Part 6 of the [Your Office Network](/blog?category=guides) series. Next up: [The Cabling in Your Walls](/blog/office-network-cabling), on why the physical cable is the most overlooked component in your network and how old or damaged cabling creates problems that are maddening to diagnose.*

---

### Part 7: The Cabling in Your Walls: Why Bad Cable Breaks Calls

URL: https://voiptest.com/blog/office-network-cabling
Published: 2026-04-01
Tags: office-network, ethernet-cabling, cat5e, cat6, cable-testing, infrastructure

*Your Office Network: Part 7 of 10*

Every network discussion eventually gets to switches, routers, VLANs, and QoS. Those are the things you configure. But underneath all of that configuration sits a physical reality: copper wire in the walls, terminated into jacks, punched into patch panels, connected by patch cables. That cabling is the physical foundation of your entire network, and when it has problems, everything built on top of it has problems too.

The frustrating part is that cable problems rarely cause a clean failure. A bad cable does not usually stop working entirely. Instead, it works most of the time and fails some of the time, in a pattern that seems random, is difficult to reproduce, and makes you question your own troubleshooting.

For VoIP, this matters more than it does for most other applications. And the reason goes back to a fundamental difference in how voice and data handle errors.

## Why cabling problems hit voice harder than data

When you download a file or load a web page, the underlying protocol (TCP) detects lost or corrupted packets and retransmits them. If a bad cable corrupts a packet, TCP notices, requests the data again, and the file arrives intact. The download might slow down slightly, but it completes correctly. You might not notice anything at all.

Voice does not work this way. VoIP uses UDP, which does not retransmit. A voice packet that arrives corrupted or does not arrive at all is simply gone. There is no mechanism to request it again because by the time the retransmission would arrive, the conversation has moved on. The moment has passed.

This means that a cable with a marginal connection, one that introduces errors on perhaps 0.5 percent of packets, can be essentially invisible to normal data usage while causing noticeable [choppy or robotic audio](/blog/choppy-robotic-audio) on voice calls. Web browsing works fine. File transfers complete. Email arrives. But phone calls have intermittent quality issues that nobody can pin down.

This is why cabling is worth an entire post in this series. It is the most overlooked component in most office networks, and when it is the source of a problem, the symptoms point everywhere except at the cable.

## Cable categories: what the labels mean

Ethernet cables are classified by category, which defines their performance specifications. The category determines the maximum frequency the cable can carry and, consequently, the maximum data rate it supports over a given distance.

One clarification before the distance figures below: the familiar 100-meter limit is a *channel* limit under ANSI/TIA-568: the whole path from device to switch, budgeted as up to 90 meters of *permanent link* (the fixed cable in the walls, jack to patch panel) plus roughly 10 meters total of patch cords at the two ends. If your in-wall runs already approach 90 meters, long patch cables can quietly push the channel out of specification even though every individual piece looks fine.

### Cat3

Category 3 cable was designed for 10 megabit Ethernet and traditional telephone systems. If your building had a legacy phone system with analog lines running to every desk, those cables are almost certainly Cat3. You can identify it by the markings printed on the cable jacket, which should say "CAT3" or "Category 3."

Cat3 is not suitable for modern networking. It cannot reliably support 100 megabit Ethernet, let alone gigabit. It has two or four pairs of wires, but the twist rate (the number of twists per inch, which is critical for canceling electromagnetic interference) is too low for higher speeds. If your building's data cabling is Cat3, it needs to be replaced. There is no configuration that makes Cat3 work for a modern VoIP deployment.

One nuance: if your building has Cat3 running from a legacy phone system, those cables were probably run to every desk and are terminated in a phone-style patch panel. You cannot repurpose those cables for Ethernet. They need to be replaced with proper data cabling.

### Cat5

Plain Category 5 (not Cat5e) was the standard for 100 megabit Ethernet in the late 1990s. It has four pairs of wire and supports 100BASE-TX at distances up to 100 meters. You will find it in buildings wired during roughly 1995 to 2002.

Cat5 is marginal for modern use. The 1000BASE-T standard (gigabit Ethernet) technically requires Cat5e as a minimum. Plain Cat5 cables will sometimes negotiate a gigabit link successfully, especially on shorter runs, but they were not designed or tested for that speed and may introduce errors under load that show up as intermittent problems.

For VoIP, Cat5 can work if the runs are short and the cables are in good condition. But if you have Cat5 cabling and you are experiencing intermittent quality issues, the cabling should be high on your suspect list. Testing the cables (more on this below) can tell you whether they meet Cat5e performance specifications even if they are labeled Cat5.

Cat5 also supports [PoE](/blog/office-network-poe) in good condition: standard IEEE 802.3af/at power actually travels over just two of the four pairs, though gigabit data needs all four and the newer four-pair IEEE 802.3bt levels need all four for power as well. But the lower twist rate compared to Cat5e means it is more susceptible to interference, which can cause problems when power and data share the same cable.

### Cat5e

Category 5e (the "e" stands for enhanced) is the minimum recommended cable for modern office networks. It supports gigabit Ethernet at distances up to 100 meters and is the baseline for reliable PoE delivery. Cat5e became the standard in the early 2000s and is still the most commonly installed cable in buildings wired in the last 20 years.

If your building has Cat5e cabling in good condition, there is no urgent need to replace it. It will handle gigabit speeds, PoE, and VoIP without issues. The "minimum" label does not mean it is inadequate. It means it meets the requirements with appropriate margin.

### Cat6

Category 6 cable offers better performance than Cat5e, with tighter twist rates, better separation between wire pairs, and support for 10 gigabit Ethernet at distances up to 55 meters. For gigabit Ethernet (which is what most office networks actually run), Cat6 provides more headroom against interference and crosstalk.

For a new installation, Cat6 is the recommended choice. The cost premium over Cat5e is modest, and the improved performance margin means the cabling will be more tolerant of slightly imperfect terminations, longer-than-ideal runs, and proximity to interference sources. It also provides a degree of future-proofing if you eventually need 10 gigabit speeds on some runs.

### Cat6a

Category 6a supports 10 gigabit Ethernet at the full 100-meter distance. It is a thicker, heavier cable that is more expensive and harder to work with. For most office environments, Cat6a is future-proofing beyond what current needs require.

The main use case for Cat6a in a typical office is the cable run from the network closet to a wireless access point that might someday need a 10 gigabit uplink. If you are pulling new cable and the cost difference is acceptable, Cat6a on access point runs is a reasonable investment. For desk runs to phones and computers, Cat6 is sufficient.

## Common cable problems

Cabling fails in ways that are more varied and more insidious than most people expect. Here are the problems that show up most often in office environments.

### Damaged connectors

The RJ45 connector at the end of a patch cable, or the jack in the wall plate, is a mechanical connection with eight tiny metal contacts. Those contacts can be bent, corroded, or worn. A connector that has been plugged and unplugged many times develops wear on the contact surfaces. A connector that was crimped poorly during installation might have one or more wires that are not making solid contact.

The result is an intermittent connection. The cable works fine when nothing is touching it, but a slight vibration, a temperature change that causes metal to expand or contract, or just the weight of the cable pulling on the connector can break contact momentarily. That momentary break drops packets. For data, TCP retransmits. For voice, the audio stutters.

### Kinks and tight bends

Ethernet cable has a minimum bend radius. Cat5e and Cat6 should not be bent tighter than about four times the cable diameter. When cable is kinked or bent sharply, the internal wire pairs can be pushed out of their proper position, changing the electrical characteristics of the cable. In extreme cases, the insulation on individual wires can be damaged, allowing them to short against each other.

Kinks often happen at wall plates where too much cable was pushed into a small junction box, or behind furniture where cables are bent around tight corners. The cable might test fine with a basic continuity tester because the wires are not broken, but the altered electrical characteristics can cause errors at higher speeds.

### Pinched cables

When cables run through walls, ceilings, or floors, they can be pinched by furniture, caught in ceiling tile grids, or compressed by cable ties that are too tight. A pinched cable has the same problem as a kinked one: the physical deformation changes the electrical characteristics.

This is particularly common when someone runs cables under carpet, through doorways, or along the base of walls where chairs roll over them. The damage accumulates over time and may not be apparent until the cable starts causing errors.

### Electromagnetic interference

Ethernet cables that run parallel to electrical power cables can pick up electromagnetic interference (EMI). The twist in the wire pairs is specifically designed to cancel out external interference, but if the cable runs alongside a high-power circuit for a long distance, the interference can exceed what the twisting can handle.

The most common scenario is cable runs through conduit that also carries power wiring, or cables that are laid directly on top of fluorescent light ballasts in a drop ceiling. The interference introduces noise on the signal, which the receiving device interprets as errors.

Cat6 and Cat6a cable are more resistant to EMI than Cat5e because of their tighter twist rates and (in Cat6a) additional shielding. But the best solution is to maintain physical separation between data and power cables, ideally at least 12 inches, and to cross power cables at 90-degree angles rather than running parallel.

### Poor terminations

Every cable in your building was terminated by someone, either at the factory (for patch cables) or by an installer (for in-wall runs). A proper termination has each of the eight wires inserted fully into the correct position and making solid contact. An improper termination might have wires in the wrong order, wires not fully seated, too much untwisted wire exposed at the termination point, or the jacket not properly secured.

Poor terminations are especially common when cables were installed by someone without proper training or tools. The cable might pass a basic continuity test (all eight wires connect from end to end) but fail a performance test because the untwisted wire length at the termination exceeds the specification, introducing crosstalk.

### Water damage and age

Cables in exterior walls, below-grade installations, or buildings with water intrusion issues can absorb moisture. Water in the cable changes its electrical characteristics dramatically, and once a cable has been wet, its performance is permanently degraded even after it dries.

Age alone can also degrade cable performance. The insulation on older cables can become brittle and crack, especially in environments with temperature extremes. The jacket can shrink, putting stress on the connectors. After 15 to 20 years, even a properly installed cable may not meet its original performance specifications.

## How cable problems show up

The symptoms of cable problems depend on the severity and the type of failure. Here is what to watch for.

**Intermittent connection drops.** The device loses its network connection briefly, reconnects, then works fine for a while before dropping again. This typically indicates a marginal physical connection at a connector.

**Speed negotiation failures.** A device that should connect at gigabit speed instead connects at 100 megabits. This often means one or more wire pairs are not working, and the switch and device have fallen back to a speed that only requires two pairs.

**Intermittent voice quality issues.** [Choppy audio](/blog/choppy-robotic-audio), brief dropout during calls, or audio artifacts that come and go. The cable is introducing enough errors to cause occasional [packet loss](/blog/understanding-voip-packet-loss), but not enough to disrupt data applications that can retransmit.

**CRC errors on switch ports.** If you have a [managed switch](/blog/office-network-switches), check the port statistics. A port connected to a bad cable will show CRC (Cyclic Redundancy Check) errors, which indicate corrupted frames arriving at the switch. A healthy port should show zero or very close to zero CRC errors over an extended period.

**Problems that correlate with physical events.** Quality issues that happen when someone moves something on their desk, when the HVAC system kicks on (causing vibration), or when the office temperature changes. These suggest a marginal physical connection that is sensitive to movement or thermal expansion.

## Testing your cables

There are two levels of cable testing, and the difference matters.

### Basic cable testers ($20 to $50)

A basic cable tester checks continuity: are all eight wires connected from one end to the other, and are they in the correct order? It will catch cables with broken wires, cables that were wired in the wrong pin order, and cables with shorts between wires.

What a basic tester will not catch is performance problems. A cable can pass a continuity test with flying colors while still failing to support gigabit Ethernet reliably because of excessive crosstalk, insufficient twist rate, or impedance mismatches from poor terminations. Basic testers are good for catching obvious problems and for verifying that newly terminated cables have the wires in the right order, but they cannot tell you whether a cable will perform at its rated speed.

### Cable certifiers ($2,000 to $15,000)

A cable certifier performs a comprehensive battery of tests that measure the cable's actual electrical performance against the ANSI/TIA-568 (or ISO/IEC 11801) specifications for its rated category. It measures insertion loss, return loss, crosstalk (NEXT and FEXT), propagation delay, and cable length. At the end, it gives you a pass or fail result for a specific cable category.

Two caveats worth knowing before you read a certification report. First, certifiers test in one of two modes that match the TIA-568 limits: *permanent link* (just the fixed cabling, jack to patch panel, tested with the certifier's reference adapters) or *channel* (the whole path including patch cords). A run can pass as a permanent link and still fail as a channel once real-world patch cables are added, so know which mode the report reflects. Second, "certified" in a contractor's proposal sometimes means something more specific than a passing test: cabling vendors' warranty programs (Panduit, CommScope, Leviton, and others) require installation by an authorized installer using that vendor's components, with certification results submitted to the vendor. A passing Fluke report from any competent tech tells you the cable performs; it does not by itself confer a manufacturer warranty.

There is also a middle tier of tool called a cable *qualifier*, which tests whether a link can carry a given Ethernet speed but does not certify it against the TIA category specifications. Useful for quick triage, but not the same thing as certification.

Certifiers are expensive tools, and most offices do not own one. But low-voltage cabling contractors have them, and a contractor can certify all your cable runs for a reasonable fee, typically a few dollars per run. If you are in a building with older cabling and experiencing intermittent network problems, having the cabling certified is one of the most cost-effective diagnostic steps you can take.

## When to replace your cabling

Not every cable problem requires ripping out the entire building's cabling. Here is a practical decision framework.

**Cat3: always replace.** Cat3 cannot support modern data rates. (Pedantically, the original IEEE 802.3af PoE was specified to work even over Cat3, but that is academic when the cable cannot carry the data.) If your data network is running on Cat3, that is your problem and new cabling is the solution. There is no workaround.

**Cat5 (plain, not Cat5e): test and plan.** Have the cables tested with a certifier. If they pass Cat5e specifications (many Cat5 cables actually will, especially on shorter runs), you can continue using them with confidence. If they fail, plan for replacement, prioritizing the runs that serve voice devices first.

**Cat5e with specific problems: replace the problem runs.** If you have mostly Cat5e cabling and specific runs are showing errors, replace those individual runs. There is no need to recable the entire building because of a few bad cables.

**Multiple failures across the building: full recable.** If testing reveals widespread failures, especially in a building with cabling that is 15 or more years old, a full recable is usually more cost-effective than chasing individual failures. The labor to test, diagnose, and individually replace problem cables adds up quickly, and at some point, starting fresh with new cable is cheaper and gives you a known-good foundation.

## Labeling: the highest-value, lowest-cost improvement

This is not about cable quality per se, but it is about cabling, and it is the single most valuable thing you can do that costs almost nothing.

Label both ends of every cable run. The jack at the desk should have a number that matches the port on the [patch panel](/blog/office-network-closet) in your network closet. If you plug a phone into jack 47 at a desk, you should be able to walk to the network closet and immediately find port 47 on the patch panel.

This sounds obvious, and yet a remarkable number of office networks have unlabeled or mislabeled cable runs. When something goes wrong, the first step in troubleshooting is figuring out which cable run the affected device is on. Without labels, that means plugging in a cable tester at the desk and having someone in the network closet test each patch panel port one by one until you find the match. That process can take 20 minutes per cable run. With labels, it takes 5 seconds.

If your cabling is not labeled, buy a label maker and a Saturday afternoon of someone's time. Walk every desk, identify which patch panel port it connects to, and label both ends consistently. Use a numbering scheme that makes sense for your office. The convention does not matter as long as it is consistent and both ends match.

While you are at it, label which [switch](/blog/office-network-switches) port each patch panel port connects to. A patch cable from patch panel port 47 to switch port Gi1/0/12 means you can go from "the phone on desk 47 has a problem" to "check switch port Gi1/0/12" in seconds.

## The connection to everything else in the series

Good cabling is the foundation that everything else depends on. [VLANs](/blog/office-network-vlans) do not help if the physical cable is dropping packets. [QoS](/blog/office-network-qos) cannot prioritize traffic that never arrives because the cable corrupted it. And while standard IEEE 802.3af/at [PoE](/blog/office-network-poe) delivers power over two pairs, gigabit data and the higher-power four-pair IEEE 802.3bt levels (what Cisco's Catalyst PoE configuration guides cover as UPOE/UPOE+) need all four, so a cable with one bad pair drops your phone to 100 Mbps at best and breaks four-pair power delivery entirely.

When you are [diagnosing VoIP problems](/blog/diagnosing-voip-problems), the cabling should be on your checklist, especially for intermittent issues that defy other explanations. Running a [VoIP quality test](/tools/voip-test) before and after cabling work gives you concrete numbers to confirm whether the new or repaired cables actually resolved the problem. It is not the most glamorous part of networking, but it is the part that makes everything above it possible.

## What comes next

Now that we have covered the physical layer from [switches](/blog/office-network-switches) through [PoE](/blog/office-network-poe) and cabling, we move to the device that connects your entire network to the internet: your router. It is doing more than you think, and some of what it is doing is actively making your VoIP problems worse.

---

*This is Part 7 of the [Your Office Network](/blog?category=guides) series. Next up: [Your Router Is Doing More Than You Think](/blog/office-network-router), covering NAT, SIP ALG, firewalls, DNS, and why your router might be the biggest VoIP troublemaker in the building.*

---

### Part 8: Your Router Is Doing More Than You Think

URL: https://voiptest.com/blog/office-network-router
Published: 2026-04-01
Tags: office-network, router, nat, sip-alg, firewall, dns, dhcp

*Your Office Network: Part 8 of 10*

Most people think of their router as the box that connects the office to the internet. That is accurate, as far as it goes. But the router is also the device making decisions about address translation, firewall rules, DNS resolution, DHCP leases, and in many cases, inspecting and modifying the actual content of your VoIP traffic. Some of those decisions are essential. Some of them are actively causing your phone problems.

This post covers what your router is doing, why it matters for VoIP, and which settings to check when phones are misbehaving. If you have already read our post on [NAT traversal](/blog/sip-nat-traversal), some of this will be familiar. The difference here is the practical focus: not the theory of why NAT and SIP conflict, but the specific router settings that cause problems in real offices and what to do about them.

## NAT: the fundamental conflict

Network Address Translation is how your router lets dozens of devices share a single public IP address. Every device in your office has a private address (something in the 10.x.x.x or 192.168.x.x range), and when any of them sends traffic to the internet, the router rewrites the source address to the router's single public IP. When responses come back, the router translates them back and forwards them to the correct internal device.

For web browsing, email, file transfers, and most internet activity, NAT is completely transparent. The applications never know it is happening.

SIP is different, and the reason matters.

When your VoIP phone places a call, it sends SIP signaling messages that contain IP addresses embedded in the message body. Specifically, the phone puts its own IP address into the SDP section of the SIP message, telling the other end "send audio to this address." The problem is that the phone only knows its private address. So the SIP message says "send audio to 192.168.1.50." The router rewrites the source address in the IP packet header to the public address, but it does not touch the SIP message content. The SIP message arrives at the far end with a private, unreachable address inside it.

The result is the most common VoIP symptom in the world: [one-way audio](/blog/one-way-audio). The call connects. Signaling works fine. But audio only flows in one direction, or does not flow at all, because one or both ends are trying to send audio to an address that does not exist on the public internet.

This is covered in much more detail in the [NAT traversal post](/blog/sip-nat-traversal). For this discussion, the key point is that NAT is a function of your router, and how your router handles it directly determines whether your phones work correctly.

### What helps: the phone's own workarounds

Most modern VoIP phones and hosted phone systems have built-in mechanisms to work around NAT. They use STUN to discover their public address, or they rely on the VoIP provider's infrastructure to handle the translation. These workarounds usually work well, as long as the router does not interfere with them.

The phrase "as long as the router does not interfere" is doing a lot of work in that sentence.

## SIP ALG: the feature that breaks VoIP

SIP ALG stands for [SIP Application Layer Gateway](/blog/sip-alg-the-setting-that-breaks-everything). It is a feature built into many routers, especially consumer and small-business models, that attempts to solve the NAT problem described above. The idea is straightforward: the router inspects SIP messages as they pass through, finds the embedded private IP addresses, and rewrites them to the router's public IP address. In theory, this fixes the one-way audio problem without the phone needing to do anything.

In practice, SIP ALG is one of the most common causes of VoIP problems. The implementations in the vast majority of consumer and small-business routers are buggy, incomplete, or both. Here is what goes wrong.

**Double-rewriting.** If the phone is already using STUN to insert its public address into SIP messages, and the router's SIP ALG also rewrites those addresses, the result is a doubly-translated address that is incorrect. The phone did the right thing. The router "fixed" it into the wrong thing.

**Corrupted messages.** SIP ALG rewrites IP addresses inside the message body but does not always update the Content-Length header. The receiving end sees a message whose declared length does not match its actual length and rejects it. Calls fail to connect, or [registration fails](/blog/sip-registration) intermittently.

**Mangled encryption.** If your VoIP provider uses TLS encryption for SIP signaling (which is increasingly common and is best practice), the router cannot read the encrypted message body. Some SIP ALG implementations attempt to process these encrypted messages anyway, corrupting them in the process.

**Inconsistent behavior.** SIP ALG on many routers does not handle every SIP message type correctly. It might rewrite INVITE messages properly but mangle REGISTER messages, or handle initial requests but break re-INVITEs (which are used for call transfers and hold/resume). The result is phones that can make calls but cannot transfer them, or calls that connect but fail when put on hold.

### The fix: turn SIP ALG off

The near-universal advice from VoIP providers is to disable SIP ALG on your router. This is not controversial advice. It is standard practice. The workarounds built into phones and VoIP platforms handle NAT traversal more reliably than SIP ALG does.

The challenge is finding the setting. Different router manufacturers label it differently:

- "SIP ALG" (the most common label)
- "SIP Helper"
- "SIP Transformations"
- "Application Layer Gateway" (with SIP as one of several protocols)
- "SIP Passthrough"
- "ALG" in the firewall or NAT settings section

Some routers have SIP ALG enabled by default with no user interface option to disable it. In those cases, the solution is either a firmware update that adds the option, a command-line configuration change (if the router supports it), or replacing the router.

If you are experiencing any combination of [one-way audio](/blog/one-way-audio), registration failures, dropped calls after a fixed time, calls that fail on transfer, or intermittent call setup failures, check whether SIP ALG is enabled. Disabling it resolves the problem in a surprising number of cases.

## Firewall rules for VoIP

Your router's firewall controls which traffic is allowed to pass between your internal network and the internet. For outbound traffic (devices inside your network reaching out to the internet), most firewalls are permissive by default and allow everything. For inbound traffic (the internet trying to reach devices inside your network), most firewalls block everything by default.

VoIP requires traffic to flow in both directions, and the firewall needs to allow it.

### SIP signaling

By convention, SIP signaling over UDP or TCP uses port 5060, and TLS-encrypted SIP uses TCP port 5061 (per RFC 3261; note that TLS runs over TCP, so there is no such thing as SIP TLS on UDP 5061). Those are defaults, not discovery: the transport and port your phones actually use come from the provider's configuration and DNS lookups ([RFC 3263](https://www.rfc-editor.org/rfc/rfc3263.html)), so check the provider's documentation rather than assuming. Your phones initiate outbound connections to the provider's servers, the provider sends responses back, and those responses need to be allowed through the firewall.

Most firewalls handle this automatically through stateful inspection: because the phone initiated the outbound connection, the firewall creates a temporary rule to allow the provider's responses back in. You generally do not need to create explicit inbound firewall rules for SIP signaling as long as your phones are initiating the connections.

### RTP media (the actual audio)

RTP, the protocol that carries the actual voice audio, uses UDP ports negotiated per call in the SDP exchange: the phone and provider each announce where they want audio sent, typically from a configured range somewhere between 10000 and 65535. Because the ports change call to call, static port-forwarding rules are the wrong tool. Like SIP, the phone initiates the outbound RTP stream, and the firewall should allow the return traffic through stateful inspection.

Where this breaks down is when the firewall's state table is not maintained correctly, or when the firewall's UDP timeout is too aggressive (more on this below). If the firewall closes its state entry for the RTP stream, return audio stops flowing and you get one-way audio.

### What to check

If you suspect firewall issues, verify that:

1. Outbound traffic to your VoIP provider's documented SIP destinations and transports (conventionally UDP or TCP 5060, or TCP 5061 for TLS) is not blocked
2. The firewall is using stateful inspection and is maintaining state for UDP connections
3. The UDP state timeout is long enough to keep connections alive during normal call activity ([at least 120 seconds, preferably 300 or more](https://www.rfc-editor.org/rfc/rfc4787.html))
4. No overly aggressive intrusion prevention system (IPS) is flagging SIP traffic as suspicious and dropping it

## UDP timeout: the invisible call killer

This one is subtle and catches a lot of people. Your router's NAT table and firewall state table maintain entries for active connections. For TCP, these entries persist as long as the TCP connection is open, because TCP has explicit connection setup and teardown messages that tell the router when the connection starts and ends.

UDP has no such messages. UDP is connectionless. The router has no way of knowing when a UDP "conversation" is over, so it uses a timer. If no traffic flows through a particular NAT mapping for a set period, the router assumes the conversation is done and removes the entry.

The default UDP timeout varies by router. Some set it at 30 seconds. Some at 60. Some at 120. Enterprise-grade routers often allow you to configure it. Worth knowing when you raise this with a vendor: RFC 4787 requires that a NAT's UDP mapping not expire in under two minutes and recommends five minutes or more, so a router timing out at 30 or 60 seconds is not merely aggressive, it is out of line with the standard.

Here is how this causes problems. Your phone registers with the VoIP provider, creating a NAT mapping. The provider records the phone's public address (the router's address and the port NAT assigned). Between registration refreshes, if no calls are in progress, there may be no SIP traffic flowing for a while. If the NAT timeout is shorter than the interval between registration refreshes or keep-alive messages, the NAT mapping expires.

Now the phone thinks it is registered, but the NAT mapping that allowed the provider to reach it is gone. Inbound calls fail because the provider sends the INVITE to the old NAT mapping, which no longer exists. The phone eventually re-registers, the mapping is recreated, and things work again, until the next quiet period when the mapping expires again.

The symptom is phones that randomly become unreachable for inbound calls, usually when they have been idle for a while. Outbound calls work because making a call creates a new NAT mapping. But inbound calls fail until the phone re-registers.

### The fix

There are two approaches, and you should ideally do both.

First, reduce the phone's re-registration interval or enable SIP keep-alive messages (OPTIONS pings or CRLF keep-alives) at an interval shorter than the router's NAT timeout. If the router times out NAT entries after 60 seconds, configure the phone to send a keep-alive every 30 seconds. This keeps the NAT mapping alive.

Second, if your router allows it, increase the UDP timeout for SIP traffic. Many business-class routers let you set application-specific timeouts. Setting the SIP UDP timeout to 300 or 600 seconds gives much more margin.

## DNS: the overlooked bottleneck

Your router typically acts as the DNS server for devices on your network. When a phone needs to resolve your VoIP provider's server address, it asks the router, and the router either responds from its cache or queries an upstream DNS server.

If DNS resolution is slow, it directly affects VoIP in two ways.

**Registration delays.** When a phone boots up, it needs to resolve the address of the SIP registrar before it can [register](/blog/sip-registration). Slow DNS adds seconds to the boot process. If DNS is unreliable, registration can fail entirely, and the phone sits there unable to make or receive calls until the DNS issue resolves.

**Call setup delays.** Each outbound call requires the phone to resolve the address of the SIP proxy (unless it caches the result). Slow DNS adds delay to call setup. If you notice a consistent lag between dialing and hearing ringback, slow DNS is a possible cause.

### What to check

Log into your router and see which upstream DNS servers it is configured to use. If it is using your ISP's DNS servers, those are usually adequate but can occasionally be slow or unreliable. Switching the upstream resolvers to a well-known public DNS service (like 1.1.1.1 or 8.8.8.8) is a reasonable fix, but be careful about *mixing* resolvers that would give different answers. If you run an internal DNS server that holds private records (for an on-premises PBX, provisioning server, or internal hostnames), do not list a public resolver as a casual "secondary" alongside it. Secondary does not mean backup-only: clients and routers can and do query any listed server, so some lookups will randomly miss your internal records and phones will intermittently fail to resolve things that "should" work. In that situation, run two internal resolvers that return the same view, and let those forward to public DNS upstream.

If you have separate [VLANs](/blog/office-network-vlans) for voice and data, make sure the DNS server configuration in the DHCP scope for the voice VLAN is correct. A phone that gets the wrong DNS server, or no DNS server at all, in its DHCP lease will have registration and call setup problems.

## DHCP: different settings for different VLANs

DHCP is how devices on your network automatically receive their IP address, subnet mask, default gateway, and DNS server settings. Your router typically runs the DHCP server, although in some environments, a separate server handles it.

If you have set up [VLANs](/blog/office-network-vlans) to separate voice and data traffic (which, as we covered in that post, is highly recommended), your router needs to serve different DHCP configurations for each VLAN. The voice VLAN gets one IP address range, one set of DNS servers, and potentially one set of VLAN-specific options. The data VLAN gets different settings.

Many VoIP phones also use DHCP options to discover their provisioning server, the server that provides the phone's configuration, firmware updates, and phone directory. The most common are DHCP option 66 (TFTP server name) and option 150 (TFTP server address, originally a Cisco convention and now documented in [RFC 5859](https://www.rfc-editor.org/rfc/rfc5859.html), which gives it priority over option 66 when both are present). If these options are not configured in the DHCP scope for the voice VLAN, phones may boot but fail to pick up their configuration, resulting in phones that register but have missing features, wrong extensions, or outdated firmware.

### Common DHCP problems

**IP address exhaustion.** If the DHCP pool is too small and all addresses are leased, new devices cannot get an address. The phone plugs in and cannot connect to the network. This is more common than you might think in growing offices.

**Lease times that do not match the network.** A DHCP lease of 24 hours means a device that was temporarily on the network holds an address for a full day after it disconnects. In environments with visitors or devices that connect intermittently, guest Wi-Fi being the classic case, short leases prevent address exhaustion. A voice VLAN is the opposite situation: desk phones are stable, permanent devices on a scope you sized for them, so there is no universal "voice lease time." Long leases (a day or more) are fine there and reduce renewal churn; what matters is matching lease length to address stability, turnover, and how your DHCP failover behaves, not hitting a particular number of hours.

**Wrong gateway or DNS.** If the DHCP configuration for the voice VLAN points to the wrong default gateway, voice traffic will not route correctly. If it points to the wrong DNS server (or no DNS server), phones will fail to resolve server addresses.

## When to upgrade your router

The router is often the oldest and most neglected piece of networking equipment in an office. It was set up when the internet connection was installed, possibly years ago, and it has been running untouched ever since. Here are the signs that your router is a bottleneck.

**You cannot disable SIP ALG.** If SIP ALG is causing problems and your router does not offer a way to disable it, the router is working against you. A router that cannot be configured to stop breaking your VoIP traffic needs to be replaced.

**No Quality of Service support.** If your router has no [QoS](/blog/office-network-qos) features, voice traffic competes equally with everything else for your internet bandwidth. During [busy periods](/blog/afternoon-call-quality), large downloads or cloud backups will degrade call quality. A router with QoS lets you prioritize voice traffic on the WAN link, which is where congestion is most likely to occur.

**CPU is maxed out.** If you can check your router's CPU utilization (many have a web interface that shows this), and it is regularly above 80 or 90 percent during business hours, the router is struggling to process traffic quickly enough. High CPU on the router adds latency to every packet passing through it, voice included.

**Old firmware with no update path.** Router firmware vulnerabilities are common and serious. If your router's manufacturer has stopped releasing firmware updates, you are running known-vulnerable software on the device that sits between your network and the internet. Security aside, old firmware also means bugs that cause VoIP problems (like SIP ALG issues) will never be fixed.

**Throughput mismatch with your ISP.** If you have upgraded your [internet connection](/blog/isp-foundation) but your router cannot handle the new speed, the router becomes the bottleneck. A router rated for 100 megabits of throughput (with firewall and NAT active) will limit a 500 megabit internet connection to 100 megabits. Our [Bandwidth Calculator](/tools/bandwidth-calculator) can help you figure out how much throughput your office actually needs so you can size a replacement correctly. This is more common than you would think, because router throughput ratings are often listed under ideal conditions that do not reflect real-world traffic with firewall inspection, NAT, and QoS all active.

**Cannot handle VLAN routing.** If you have implemented [VLANs](/blog/office-network-vlans) on your switches but your router cannot route between them (inter-VLAN routing), you need either a router that supports this or a layer-3 switch. Without inter-VLAN routing, devices on different VLANs cannot communicate, which limits the usefulness of your VLAN deployment.

## What to look for in a replacement

If you determine that your router needs to be upgraded, here is what matters for a VoIP-friendly environment.

**SIP ALG that can be disabled** (or better yet, a router from a vendor that does not include SIP ALG at all).

**QoS with support for DSCP marking and priority queuing** on the WAN interface. The router should be able to read DSCP values on packets from your VoIP phones and prioritize them.

**Adequate throughput** with all features enabled. Check the rated throughput with firewall, NAT, QoS, and VPN (if you use one) all active. That number, not the headline "up to" throughput, is what your network will actually get.

**VLAN support** and inter-VLAN routing capability, if you are running or planning to run VLANs.

**Configurable UDP timeouts** for NAT and firewall state tables.

**Reliable DHCP server** with support for multiple scopes (one per VLAN) and DHCP options for phone provisioning.

**Current firmware** from a vendor with a track record of regular updates.

Business-class routers from vendors like Ubiquiti, MikroTik, Fortinet, Cisco, and others meet these requirements. The specific choice depends on your budget, your technical comfort level, and whether you have someone to manage it. But any of them will be a significant improvement over the ISP-provided residential router that many small offices are running.

## The router in context

Your router sits at a critical junction. On one side, your [local network](/blog/your-local-network) with its [switches](/blog/office-network-switches), [VLANs](/blog/office-network-vlans), and [cabling](/blog/office-network-cabling). On the other side, the [internet path](/blog/the-internet-path) to your VoIP provider. Every voice packet crosses the router twice: once on the way out, once on the way back. If the router adds latency, drops packets, corrupts SIP messages, or lets firewall rules and NAT timeouts interfere with call flow, every call on your network is affected.

The good news is that router problems, once identified, are fixable. Disable SIP ALG. Configure QoS. Adjust UDP timeouts. Set up proper DHCP scopes. Run a [VoIP quality test](/tools/voip-test) after each change to confirm it actually improved things. And if the router cannot do what you need it to do, replace it. The investment in a proper business-class router is modest compared to the ongoing cost of unreliable phone service.

---

*This is Part 8 of the [Your Office Network](/blog?category=guides) series. Next up: [WiFi for Everything Else](/blog/office-network-wifi), covering access points, channels, interference, and how to make wireless work well for everything that is not a desk phone.*

---

### Part 9: WiFi for Everything Else: Access Points, Channels, and Interference

URL: https://voiptest.com/blog/office-network-wifi
Published: 2026-04-02
Tags: office-network, wifi, access-points, channel-planning, interference, wifi6

*Your Office Network: Part 9 of 10*

Earlier in this series, we made the case that [wired connections are better for VoIP](/blog/office-network-wired-vs-wifi). That advice stands. If you can run an Ethernet cable to a desk phone, you should. The consistency of a wired connection eliminates an entire category of variables that wireless introduces, and for something as latency-sensitive as voice, that consistency matters.

But your office is not just phones. It is laptops, tablets, smartphones, conference room displays, guest devices, and an ever-growing list of things that expect wireless connectivity. Good WiFi is no longer optional for a functional office. The question is not whether to have WiFi, but how to set it up so that it works well for the dozens of devices that depend on it, without the common problems that plague poorly planned wireless networks.

This post is about getting WiFi right for everything that is not a desk phone. And at the end, we will cover how to make WiFi work for VoIP in the situations where wired is genuinely not possible.

## Access point placement: the foundation of good WiFi

The single most impactful decision in a wireless deployment is where you put the access points. Get this wrong and no amount of configuration will fix it. Get it right and most other WiFi problems either disappear or become manageable.

### Ceiling or high wall mount

Access points should be mounted on the ceiling or high on a wall, not sitting on a desk or shelf. Radio signals propagate outward and downward from a ceiling-mounted AP in a pattern that naturally covers the floor area below. An AP sitting on a desk radiates into the underside of the desk above it, the wall beside it, and the floor at an angle, wasting signal in directions where there are no devices.

Ceiling mounting also keeps the AP above most obstructions. Office furniture, partitions, people standing up, filing cabinets, all of these are between desk height and head height. An AP at ceiling height has a clearer line of sight to devices throughout the room.

Most commercial access points are designed to be ceiling-mounted. They come with mounting brackets, and their antenna patterns are optimized for that orientation. Mounting them any other way means you are working against the design.

### Coverage area per access point

How much space can one access point cover? The answer depends on the environment, but here are practical guidelines.

**Open office space** (no floor-to-ceiling walls, cubicles or open desks): one access point per 1,500 to 2,000 square feet. Radio signals travel well in open spaces, and a single AP can cover a large area.

**Offices with interior walls** (drywall, glass partitions): one access point per 800 to 1,200 square feet. Each wall attenuates the signal. Drywall reduces signal strength modestly. Glass is surprisingly lossy for WiFi, especially energy-efficient glass with metallic coatings. Brick and concrete block signal significantly.

**Dense construction** (concrete walls, metal partitions, older buildings with plaster-and-lath): one access point per 500 to 800 square feet, or one per room if rooms are fully enclosed.

These numbers are starting points, not guarantees. Every building is different, and a proper WiFi site survey (walking the space with a survey tool that maps signal strength) is the definitive way to determine AP placement. But these guidelines get you in the right range for planning purposes.

### Coverage overlap

Adjacent access points should have overlapping coverage areas. The overlap ensures that a device moving from one AP's coverage area to another does not lose connectivity during the handoff. Aim for 15 to 25 percent overlap between adjacent APs.

Too little overlap creates dead zones, pockets of weak signal where devices drop their connection or struggle to maintain it. Too much overlap wastes APs and can actually create problems if adjacent APs are on the same channel (more on channel planning below).

## Channel planning: the thing most people skip

WiFi access points operate on specific radio channels. If two nearby access points use the same channel, they interfere with each other, and every device connected to either one suffers. Channel planning is the process of assigning channels to your access points so that adjacent APs do not interfere.

### The 2.4 GHz band

The 2.4 GHz band has 11 channels available in North America (13 in most other regions), but only three of them do not overlap with each other: channels 1, 6, and 11. Every other channel overlaps with its neighbors, creating co-channel interference that is worse than if the APs were on the same channel (because same-channel devices at least coordinate their transmissions, while overlapping-channel devices do not).

The practical effect is that you have exactly three non-overlapping channels to work with in the 2.4 GHz band. In an office with more than three access points, some APs will share a channel. The goal is to ensure that APs sharing a channel are physically far enough apart that their signals do not overlap significantly.

This is a serious constraint. In a dense office with many APs, the 2.4 GHz band is essentially unusable for high-performance wireless because there are not enough channels to go around without interference. This is one of the primary reasons the 5 GHz band exists.

### The 5 GHz band

The 5 GHz band offers dramatically more channels. Depending on your region and regulatory domain, you have access to 20 or more non-overlapping channels. This makes channel planning much more flexible. Even in a large office with a dozen access points, you can assign each one a unique channel with no overlap.

The trade-off is range. 5 GHz signals do not penetrate walls as well as 2.4 GHz signals, and they attenuate faster over distance. An AP that covers 2,000 square feet on 2.4 GHz might only cover 1,200 square feet on 5 GHz. This is actually an advantage for channel planning, because the shorter range means less interference between distant APs, but it means you may need more access points for complete 5 GHz coverage.

For most office environments, 5 GHz is the better choice for primary wireless connectivity. The additional channels, reduced interference from neighboring networks, and higher potential throughput outweigh the reduced range, especially since you are already placing APs at the density needed for good coverage.

### The 6 GHz band (WiFi 6E and WiFi 7)

WiFi 6E and WiFi 7 devices can use the 6 GHz band, which provides even more channels with even less interference. The 6 GHz band is essentially empty compared to 2.4 and 5 GHz, because only newer devices can use it.

If you are deploying new access points and your devices support it, 6 GHz is excellent for high-density environments. However, many office devices, especially older laptops and IoT devices, do not have 6 GHz radios, so you will need 5 GHz coverage as a fallback for some time.

### Auto channel selection

Most modern access points and wireless controllers offer auto channel selection, where the system monitors interference and automatically assigns channels to minimize conflicts. In well-designed systems from reputable vendors, auto channel selection works well and is easier to maintain than manual channel assignments.

However, auto channel selection is not a substitute for proper AP placement. If your access points are in the wrong locations, auto channel selection will do its best with a bad situation, but it cannot overcome fundamental coverage gaps or excessive interference from APs that are too close together.

### Using a WiFi analyzer

A WiFi analyzer app (available for smartphones and laptops) shows you which channels are in use in your area, how strong the signals are, and where interference exists. Running a WiFi analyzer before deploying access points tells you which channels your neighbors are using so you can avoid them. Running it after deployment helps you identify channels with excessive interference.

For the 2.4 GHz band, a WiFi analyzer will almost certainly show you a crowded mess of overlapping networks, especially in office buildings with multiple tenants. This is normal and is another reason to prioritize 5 GHz.

## Client density: how many devices per access point

An access point has a finite amount of airtime to share among its connected devices. The more devices connected, the less airtime each one gets. This is true regardless of the AP's headline throughput speed, because throughput is shared, not per-device.

### Practical limits

A good rule of thumb for business-grade access points is 25 to 30 active clients per AP for reliable performance. "Active" means devices that are actually transmitting data, not just associated with the AP but idle. A laptop running a video conference is using significant airtime. A phone sitting in a pocket with the screen off is using almost none.

Consumer-grade access points have lower limits. Many start struggling above 10 to 15 active clients. If your office is using a consumer WiFi router as its only access point, and you have 20 people with laptops and phones connected to it, the access point is likely a bottleneck.

### Calculating your needs

Count the total number of wireless devices in your office during a typical business day. Include laptops, phones, tablets, and any other wireless devices. Assume that roughly half of them are active at any given time (this varies, but it is a reasonable starting point). Divide by 25 to get the minimum number of access points needed for client density alone.

Then compare that number to the number of APs needed for coverage. Use whichever number is higher. In open offices with lots of people, client density often requires more APs than coverage alone would dictate.

## Interference sources

WiFi operates in unlicensed radio spectrum, which means it shares the airwaves with a long list of other devices. Knowing what causes interference helps you avoid it.

**Microwave ovens.** Microwave ovens operate at 2.45 GHz, right in the middle of the 2.4 GHz WiFi band. When a microwave is running, it radiates energy that the WiFi radio perceives as noise. If an access point is near a kitchen or break room, expect 2.4 GHz performance to degrade every time someone heats their lunch.

**Bluetooth devices.** Bluetooth also uses the 2.4 GHz band. In an office full of Bluetooth headsets, mice, and keyboards, the cumulative interference on 2.4 GHz is non-trivial. This is another reason to push WiFi traffic to 5 GHz where possible.

**Neighboring WiFi networks.** In a multi-tenant office building, every other tenant's WiFi network is a source of interference for yours. You cannot control their channel selections, power levels, or equipment. All you can do is optimize your own setup and minimize the impact. Using 5 GHz helps significantly because the shorter range means neighboring networks are less likely to reach your space at meaningful signal levels.

**Cordless phones and baby monitors.** Older cordless phones and monitors use 2.4 GHz. These are less common in offices but show up occasionally.

**Building materials.** Not technically interference, but building materials affect WiFi coverage enough to mention here. Metal (ductwork, elevator shafts, steel studs) blocks WiFi almost entirely. Concrete attenuates it heavily. Low-E glass with metallic coatings is surprisingly opaque to WiFi. Water (including humans, who are mostly water) absorbs WiFi signal. When planning AP placement, account for what the signal has to pass through to reach the devices.

## WiFi security

An open WiFi network is an invitation for unauthorized access. Even in a small office, wireless security matters.

### WPA3

WPA3 is the current standard for WiFi security and should be your first choice. Its headline improvement in WPA3-Personal is a new authentication handshake called SAE (Simultaneous Authentication of Equals), which resists the offline brute-force attacks that WPA2 passphrases are vulnerable to and protects past traffic even if the passphrase is later compromised, per the Wi-Fi Alliance's WPA3 specification. One clarification, because it is widely misstated: per-device encryption keys are not new in WPA3; WPA2 already derives a unique unicast key for each connected device. If you have seen "individualized encryption" advertised, that refers to Wi-Fi Enhanced Open (OWE), a separate certification that adds encryption to otherwise open, passwordless networks such as guest hotspots.

Not all devices support WPA3. If you have older devices that only support WPA2, most access points can run in a transition mode that accepts both WPA2 and WPA3 connections. This is a reasonable compromise that lets you improve security for capable devices while maintaining compatibility with older ones.

### WPA2

WPA2 remains acceptable if WPA3 is not available on your access points or devices. Use WPA2 with a strong, unique passphrase. Avoid WPA (the original, not WPA2), which has known vulnerabilities that make it trivially breakable.

### Guest network

Set up a separate SSID for guests with its own passphrase and its own [VLAN](/blog/office-network-vlans). Guest devices should be able to reach the internet but should not have access to your internal network resources: file servers, printers, phone systems, or management interfaces.

Most business-grade access points support multiple SSIDs, each mapped to a different VLAN. This is one of the areas where proper VLAN configuration pays off. Your internal SSID connects to your data VLAN with full network access. Your guest SSID connects to an isolated guest VLAN with only internet access.

Change the guest password periodically. If your guest network password has been the same for two years, it is effectively public knowledge.

## WiFi for VoIP when wired is not possible

Everything above applies to general WiFi. But what about the situation where you genuinely need to run VoIP over WiFi? Maybe you have softphone users on laptops who move between conference rooms. Maybe you have a small office where running cables to every desk is impractical. Maybe you have a warehouse or retail space where wired connections are impossible.

VoIP over WiFi can work. The key is minimizing the variables that wireless introduces. Here is how.

### Use 5 GHz (or 6 GHz)

Put VoIP devices on the 5 GHz band. The reduced interference and additional channels make a meaningful difference for voice quality. If your access points support band steering, enable it to push capable devices to 5 GHz automatically.

### Enable WMM

Wi-Fi Multimedia (WMM) is a [QoS](/blog/office-network-qos) mechanism for WiFi, defined in the Wi-Fi Alliance's WMM specification. It gives voice-classified traffic priority over other wireless traffic at the air interface. Most business-grade access points support WMM and many have it enabled by default. Verify that it is on.

Mechanically, WMM works through EDCA (Enhanced Distributed Channel Access): traffic is sorted into four access categories, and frames in the voice category get more aggressive channel-contention parameters, so they statistically win access to the airwaves sooner. Both sides use it (the AP for downstream traffic and the client devices for upstream), so it is not merely downstream prioritization; a voice-capable client contends for airtime with the same advantage. What WMM cannot do is eliminate the fundamental variability of wireless transmission: priority improves your odds in the contention lottery, it does not create a reserved lane. But it helps in both directions, and there is no reason not to enable it.

### Maintain strong signal strength

For VoIP over WiFi, the common design target is -65 dBm or stronger at the device, ideally -60 dBm. These are engineering targets used in voice-grade WiFi designs rather than a threshold from any standard, but the reasoning behind them is real: as signal weakens toward -70 dBm, error rates climb and retransmissions become frequent enough to cause audible [jitter](/blog/what-is-jitter-and-why-it-matters).

You can check signal strength on most devices: on a laptop, the WiFi status typically shows signal strength in the advanced connection details. On phones, there are apps that display it. If VoIP devices are consistently below -65 dBm, you need either closer access points or more of them.

### Reduce client load

If possible, put VoIP WiFi devices on a dedicated SSID with fewer competing clients. Even if the SSID maps to the same VLAN, having fewer devices associated with the VoIP-prioritized SSID can reduce contention for airtime.

### Disable power save mode

WiFi power save mode puts the radio to sleep between transmissions to conserve battery. When a packet arrives while the radio is asleep, there is a delay while it wakes up. For VoIP, this delay adds [jitter](/blog/what-is-jitter-and-why-it-matters). Most laptops and phones have power save enabled by default for WiFi. On devices used for VoIP, consider disabling it (recognizing the battery life trade-off).

### Set expectations

Even with all of these optimizations, WiFi VoIP will not match the consistency of a wired connection. Running a [VoIP quality test](/tools/voip-test) from a WiFi-connected device during peak office hours will show you exactly how much jitter and loss your wireless setup is introducing. If you are running VoIP over WiFi because wired is impractical, communicate to users that occasional quality variations are inherent to the technology. The difference between a well-configured WiFi VoIP setup and a poorly configured one is significant, but the difference between WiFi VoIP and wired VoIP is always present.

## The all-too-common WiFi mistakes

Before we wrap up, here are the WiFi mistakes that show up in offices repeatedly.

**One access point for the entire office.** A single consumer router in the corner of a 3,000 square foot office. Half the space has weak signal, and 40 devices are competing for airtime on one radio. Add more access points.

**All access points on the same channel.** Three APs, all on channel 6, all interfering with each other. Devices connected to one AP hear transmissions from the other two as noise, reducing effective throughput for everyone. Plan your channels.

**2.4 GHz only.** Many devices default to 2.4 GHz because it has longer range. But in an office building, 2.4 GHz is usually the most congested band. Enable 5 GHz and configure band steering to move capable devices off 2.4 GHz.

**APs hidden in closets or mounted at floor level.** An AP inside a cabinet or under a desk is radiating into furniture and floor instead of into the room. Mount them on the ceiling where they are designed to be.

**No guest network.** Everything on one SSID, one network. Visitors and employees sharing the same wireless network with no isolation. Create a separate guest network on a separate VLAN.

**Consumer equipment in a business environment.** Home WiFi routers and mesh systems are designed for residences with a handful of devices. They lack the client capacity, channel management, and VLAN support that an office with 20 or more wireless devices needs. Business-grade access points are not dramatically more expensive and are dramatically more capable.

## What comes next

This is the second-to-last post in the series. We have covered the [network closet](/blog/office-network-closet), [wired vs. WiFi](/blog/office-network-wired-vs-wifi), [switches](/blog/office-network-switches), [VLANs](/blog/office-network-vlans), [QoS](/blog/office-network-qos), [PoE](/blog/office-network-poe), [cabling](/blog/office-network-cabling), your [router](/blog/office-network-router), and now WiFi. The final post brings it all together: how to recognize when your network has outgrown its equipment, what to upgrade first, and how to make the case for the investment.

---

*This is Part 9 of the [Your Office Network](/blog?category=guides) series. Next up: [When Your Network Outgrows Its Equipment](/blog/office-network-upgrade-signs), on the signs that it is time to upgrade, what to prioritize, and what it actually costs.*

---

### Part 10: When Your Network Outgrows Its Equipment: Signs You Need to Upgrade

URL: https://voiptest.com/blog/office-network-upgrade-signs
Published: 2026-04-02
Tags: office-network, network-upgrade, capacity, equipment, planning

*Your Office Network: Part 10 of 10*

There is a pattern that plays out in offices everywhere. The business starts small. The ISP installs a combo modem-router. Someone buys an 8-port switch from the electronics store to add more ports. A consumer WiFi router gets plugged in for wireless. Phones get connected, computers get connected, and everything works well enough.

Then the office grows. More people, more devices, more cloud applications, more video calls. The problems are subtle at first. Calls that sound fine most of the time but occasionally get [choppy](/blog/choppy-robotic-audio). WiFi that slows down in the afternoon. A phone that inexplicably reboots every few days. Nothing bad enough to be an emergency, but a steady accumulation of small frustrations that everyone learns to work around.

This is the normal trajectory. Almost every small business goes through it. The question is not whether your network will outgrow its equipment, but whether you recognize when it has, and what to do about it.

## The typical growth pattern

Understanding how networks typically evolve helps explain why the problems emerge.

**Stage 1: The ISP box.** The internet connection comes with a combo device that handles routing, WiFi, and sometimes even a few Ethernet ports. For a handful of people, this works. The device was designed for a home with a few family members, and a tiny office with three people is not that different.

**Stage 2: The cheap switch.** The ISP box does not have enough Ethernet ports, so someone buys a small unmanaged switch and plugs it in. Now there are more ports. The switch costs $30 and has no management features, no [QoS](/blog/office-network-qos), no [VLAN](/blog/office-network-vlans) support, and no [PoE](/blog/office-network-poe). But it provides ports, and that is what was needed.

**Stage 3: Growing pains.** The office has grown to 10, 15, or 20 people. Someone adds another switch. Maybe a second WiFi router gets plugged in for better coverage. Cables are run wherever they fit, some through walls, some across the floor, some held together with cable ties and hope. The network is a patchwork of consumer-grade equipment connected ad hoc over time.

At this stage, the network still mostly works. But "mostly" is doing a lot of heavy lifting. The problems are intermittent, hard to pin down, and easy to blame on the VoIP provider or the internet connection. And that is exactly where this post picks up.

## Six signs your network has outgrown its equipment

### 1. Unexplained call quality problems despite a good internet connection

This is the most telling sign, and the most commonly misdiagnosed. You have a solid internet connection. Your [ISP](/blog/isp-foundation) says the line is clean. Your VoIP provider says their platform is fine. But calls still have intermittent quality issues: [choppy audio](/blog/choppy-robotic-audio), [jitter](/blog/what-is-jitter-and-why-it-matters), brief dropouts, or [audio that sounds robotic](/blog/choppy-robotic-audio).

When the ISP is not the problem and the VoIP provider is not the problem, the internal network is the third variable in the blame game. And it is the variable nobody thinks to check because it is "just switches and cables."

The reality is that an internal network with no QoS, cheap unmanaged switches, and consumer-grade routing can introduce enough [latency and packet loss](/blog/understanding-voip-packet-loss) to degrade voice quality even on an excellent internet connection. A [VoIP quality test](/tools/voip-test) can help you confirm whether the problem is inside your building or further upstream. The problem is not the pipe to the internet. The problem is what happens to voice packets between the phone and the router.

### 2. Slow performance during busy periods

If the network feels fast in the morning but bogs down after lunch, or if everything slows to a crawl when someone starts a large file upload or a video conference, you are seeing the symptoms of a network with no traffic management.

Without [QoS](/blog/office-network-qos), all traffic competes equally for bandwidth. A cloud backup uploading gigabytes of data gets the same priority as a phone call. A software update downloading on 15 machines simultaneously gets the same treatment as the CEO's client call. The available bandwidth gets split up by whatever happens to arrive first, and time-sensitive traffic like voice loses every time.

This is particularly painful when combined with [afternoon call quality degradation](/blog/afternoon-call-quality). The busiest period of the day is also the period when the most people are on calls, and it is exactly when the network is least able to handle them.

### 3. Running out of ports and daisy-chaining switches

When you need more Ethernet ports than your switch has, the tempting solution is to buy another small switch and plug it into the first one. When that one fills up, buy another one and plug it into the second. This is daisy-chaining, and it is a red flag.

Each switch in the chain adds latency. Each connection between switches is a potential bottleneck (especially if the daisy-chain link is the same speed as the individual device connections, meaning all traffic between the two switches shares a single port's bandwidth). None of the switches have management features, so there is no way to prioritize traffic or monitor what is happening on the network.

If you have more than two switches connected in a chain, or if your "switch" is actually a consumer WiFi router being used as a switch because you needed the extra ports, it is time to consolidate into a single managed switch with enough ports.

### 4. Phones and computers on the same flat network

If every device in your office, phones, computers, printers, the break room smart TV, and guest laptops, is on the same network with the same IP address range and no separation, you have a flat network.

A flat network means a [broadcast storm](/blog/your-local-network) from one misbehaving device affects everything, including active phone calls. It means a rogue device or malware on a guest's laptop is on the same network as your phone system. It means there is no way to prioritize voice traffic at the switch level because there is no separation between voice and data.

[VLANs](/blog/office-network-vlans) solve this by creating logical separation on the same physical equipment. But VLANs require managed switches and a [router](/blog/office-network-router) that supports inter-VLAN routing. If your equipment cannot do VLANs, that is a clear sign it needs to be upgraded.

### 5. WiFi cannot handle the device count

Every year, the number of wireless devices per person increases. A person in your office might have a laptop, a phone, a tablet, and a smartwatch, all connected to WiFi. Twenty people means 60 or more wireless devices competing for airtime on the same access points.

If your WiFi is a consumer router or two, each handling 30 to 40 connections, performance will be poor. Devices on the fringe of coverage will constantly disconnect and reconnect. Video calls will freeze. File downloads will stall.

The signs are obvious: complaints about WiFi speed, devices showing "connected" but unable to load anything, and a general perception that "the WiFi is terrible." The cause is almost always either too few access points, access points that cannot handle the client density, or poor [channel planning](/blog/office-network-wifi).

### 6. The router is the bottleneck

This one ties back to everything we covered in the [router post](/blog/office-network-router). Your router might be the bottleneck if:

**Its CPU is maxed out.** Many consumer and small-business routers have processors that are adequate for home use but struggle under office workloads. If the router's management interface shows sustained high CPU utilization, every packet is being delayed.

**It has no QoS support.** If the router cannot prioritize traffic, voice competes with everything else at the most critical point in the network: the WAN link. This is where congestion is most likely, and where QoS has the most impact.

**SIP ALG cannot be disabled.** If the router is actively breaking your VoIP traffic with a buggy [SIP ALG](/blog/sip-nat-traversal) implementation and there is no way to turn it off, the router is working against you.

**Firmware is outdated with no update path.** If the manufacturer has end-of-lifed the router and is no longer releasing updates, you are running known-vulnerable software on your internet gateway. This is a security issue as much as a performance issue.

**Throughput does not match your internet speed.** If you upgraded your internet to 500 megabits but your router's actual throughput (with NAT, firewall, and any VPN active) is 100 megabits, you are paying for speed you cannot use.

## The upgrade path: prioritized by impact

If your network is showing several of these signs, you do not need to replace everything at once. Here is the order that delivers the most improvement for the money.

### First: a managed PoE switch

Replace the daisy-chained consumer switches with a single managed PoE switch that has enough ports for all your devices, plus room to grow. A 24 or 48-port managed PoE switch gives you:

- Enough ports to eliminate daisy-chaining
- [PoE](/blog/office-network-poe) to power phones and access points from the switch, simplifying cable runs and enabling UPS backup for phones
- [VLAN support](/blog/office-network-vlans) to separate voice and data traffic
- [QoS](/blog/office-network-qos) at the switch level to prioritize voice traffic internally
- Port monitoring and statistics to help diagnose problems
- Proper management interface to configure and monitor the network

This single upgrade addresses signs 2, 3, and 4. It is typically the highest-impact change you can make.

### Second: a business-class router

Replace the ISP combo box or consumer router with a business-class router that supports QoS on the WAN interface, VLAN routing, configurable NAT timeouts, and ideally has no SIP ALG at all.

This addresses sign 6 and significantly helps with signs 1 and 2. With QoS on the WAN link, voice traffic gets priority over everything else at the point where congestion actually occurs.

### Third: proper wireless access points

Replace consumer WiFi routers with business-grade ceiling-mounted access points, properly placed and configured with appropriate [channel planning](/blog/office-network-wifi). If you have a managed switch with PoE, the access points can be powered directly from the switch, simplifying installation.

This addresses sign 5 and dramatically improves wireless performance for everyone.

### Fourth: cabling

If you are in a building with older [cabling](/blog/office-network-cabling) (Cat5 or Cat3), or if cable testing reveals problems, address the cabling last. This is the most expensive and disruptive upgrade, but it is also the most durable. Properly installed Cat6 cabling will serve the office for 15 to 20 years.

If cabling is in good shape (Cat5e or Cat6, properly terminated, recently tested), skip this step entirely. Do not replace working cable for the sake of replacing it.

## Cost reality

The question everyone asks is "what does this actually cost?" Here are realistic numbers for a 20-person office.

**Managed 24-port PoE switch:** $300 to $800, depending on brand and features. Ubiquiti, TP-Link Omada, and Netgear offer good options at the lower end. Cisco and Aruba at the higher end. Any of them are a massive improvement over unmanaged consumer switches.

**Business-class router:** $200 to $600. Ubiquiti EdgeRouter or UniFi Dream Machine, MikroTik, Fortinet FortiGate, or similar. At the higher end, you get more sophisticated features, but even the entry-level options provide QoS, VLAN support, and configurable NAT.

**Wireless access points (2 to 3 for a typical 20-person office):** $100 to $300 each, so $200 to $900 total. Ubiquiti UniFi, TP-Link Omada, or similar. Ceiling-mount, 802.11ac or WiFi 6, with PoE power.

**Cabling (if needed, 20 cable runs):** $100 to $200 per run, professionally installed and certified. So $2,000 to $4,000 for a full recable. This is the big-ticket item but is only necessary if existing cabling is Cat3 or has significant problems.

**Total without cabling:** $700 to $2,300.

**Total with cabling:** $2,700 to $6,300.

If you are not sure where your network stands, our [Bandwidth Calculator](/tools/bandwidth-calculator) can help you estimate whether your current connection and equipment can handle your actual call volume and device count.

For a 20-person office where phone reliability matters, this investment pays for itself quickly. Consider what unreliable phones actually cost: the dropped call with a prospect, the support issue that required a callback because the call dropped, the daily frustrations of the staff person whose phone reboots every afternoon, the IT time spent chasing intermittent problems that would not exist on proper equipment. None of those costs show up on an invoice, but they are real.

## When to bring in help

Not every upgrade requires a professional. Replacing a switch and plugging in cables is straightforward. Configuring VLANs and QoS requires more knowledge but is well-documented for most business-grade equipment.

But there are situations where professional help is worth the cost.

**Cabling installation.** Running cable through walls, ceilings, and conduit is skilled work. Poor installation creates the exact problems we covered in the [cabling post](/blog/office-network-cabling). A low-voltage cabling contractor does this daily and will do it right.

**Complex VLAN and QoS configuration.** If you have multiple VLANs, inter-VLAN routing, QoS policies, and a mix of device types, the configuration can get complex. A network consultant who specializes in SMB environments can set this up correctly in a few hours and save you days of trial and error.

**WiFi site surveys.** A proper site survey with calibrated equipment produces an accurate coverage map and optimal AP placement plan. This is especially valuable in buildings with unusual construction or challenging layouts.

**Ongoing management.** If nobody in the office has the time or inclination to monitor and maintain the network, consider a managed service provider. The monthly cost is typically less than the productivity lost to network problems.

## The series thesis, now that you have seen the whole picture

We started this series in the [network closet](/blog/office-network-closet), looking at the physical equipment that makes up your network. We covered [wired vs. WiFi](/blog/office-network-wired-vs-wifi), [switches](/blog/office-network-switches), [VLANs](/blog/office-network-vlans), [QoS](/blog/office-network-qos), [PoE](/blog/office-network-poe), [cabling](/blog/office-network-cabling), [routers](/blog/office-network-router), and [WiFi](/blog/office-network-wifi). Each post covered one piece. Together, they form a complete picture of what is inside your network and how it affects your phones.

The thesis of this series is simple: your internal network is the part of the VoIP quality equation that nobody thinks about, and it is the part you can actually fix.

When call quality is bad, the instinct is to blame the VoIP provider or the internet connection. And sometimes those are the problem. But in a remarkable number of cases, the problem is inside the building. A flat network with no QoS. An overloaded consumer router with SIP ALG enabled. Daisy-chained unmanaged switches. Old cabling with intermittent failures. An access point from 2015 trying to serve 40 devices.

These are all fixable. They are fixable at a cost that is modest relative to the problem they cause. And once they are fixed, they stay fixed. A properly configured network does not need constant attention. It needs occasional updates and monitoring, but it does not create the steady drumbeat of unexplained problems that an ad-hoc network does.

You now know what is in your network, what each component does, and what to look for when something goes wrong. That is more than most business owners, office managers, or accidental IT people know. And it is exactly enough to make informed decisions about whether your network is serving you well or holding you back.

If something in this series described your situation, you know what to do next. If everything sounds unfamiliar and you are not sure where your network stands, start with a simple inventory: walk into the [network closet](/blog/office-network-closet), look at what is in there, and see how it compares to what this series described. That is always the first step.

---

*This is the final post in the [Your Office Network](/blog?category=guides) series. For the other side of the VoIP quality equation, the internet connection between your building and your VoIP provider, see our [ISP series](/blog/isp-foundation). For practical troubleshooting when calls sound bad, see [Diagnosing VoIP Problems](/blog/diagnosing-voip-problems).*

# Standalone Blog Posts (52 posts)

## Double NAT and VoIP: Hidden Cause of One-Way Audio

URL: https://voiptest.com/blog/double-nat-voip
Published: 2026-09-04
Category: Troubleshooting
Tags: double-nat, nat-traversal, one-way-audio, sip-alg, routers, troubleshooting

There is a network topology so common that most people running it have no idea it exists: an ISP-supplied gateway performing NAT, with the customer's own router behind it performing NAT again. Every packet leaving the network gets translated twice. Most applications shrug this off. Web browsing works, streaming works, email works, which is exactly why double NAT survives undetected for years, quietly sabotaging the one class of traffic that cannot tolerate it.

VoIP is that class. If your phones suffer from one-way audio, registrations that mysteriously lapse, inbound calls that go straight to voicemail while the handset sits idle, or calls that drop at eerily consistent durations, double NAT belongs at the top of your suspect list. This post explains how the topology comes to exist, how to confirm it in about two minutes, why it hits SIP so much harder than a single NAT layer does, and how to fix it, ranked from the clean solution to the acceptable workaround.

## The setup nobody realizes they have

Almost every ISP now ships a combination device: a modem (or ONT interface) fused with a router, Wi-Fi access point, and firewall in one box. Comcast's xFi gateways, AT&T's BGW-series units, Spectrum's leased routers: all of them are full NAT routers out of the box, handing out private addresses on their LAN side.

Then the customer, reasonably, adds their own router. Maybe the ISP box's Wi-Fi is weak and they bought a mesh system. Maybe an IT provider installed a proper firewall for the office. Maybe the old router just came along from the previous ISP. The new router's WAN port plugs into the ISP gateway's LAN port, the new router does what routers do (NAT) and now the network has two translation layers stacked in series. Devices sit on, say, 192.168.1.x behind the customer router, which sits on 192.168.254.x behind the ISP gateway, which finally holds the public IP.

Nothing announces this. Both boxes report healthy status. Speed tests look normal. The topology can persist for the entire life of the installation, and in small offices it very frequently does. We would estimate double NAT is present in a large fraction of small-business networks running an ISP combo unit plus their own firewall, and in most of them nobody has ever checked. There is a third variant worth naming: carrier-grade NAT (CGNAT), where the ISP itself performs a NAT layer in its core and hands your "public" interface a shared address. You get double NAT without a second box on the premises at all.

If you are speccing a small office network from scratch, the [office network and router guide](/blog/office-network-router) covers how to avoid building this trap in the first place.

## How to detect VoIP behind two routers

Detection takes two minutes and requires no tools beyond a browser and a terminal.

**Check your router's WAN IP.** Log into your own router (the inner one, the one your devices connect to) and find its WAN or internet status page. Note the WAN IP address, then compare it to what a "what is my IP" website reports from a device on your network. If they match, you have single NAT. If the router's WAN IP falls in a private range, there is another NAT device between you and the internet:

- **192.168.0.0 – 192.168.255.255**: the classic home range; a WAN IP of 192.168.254.254 is the AT&T gateway signature
- **10.0.0.0 – 10.255.255.255**: common on ISP gateways and CGNAT deployments
- **172.16.0.0 – 172.31.255.255**: less common, still private
- **100.64.0.0 – 100.127.255.255**: the dedicated CGNAT range (RFC 6598); a WAN IP here means your ISP is NATing you upstream, and no amount of on-premises reconfiguration removes that layer

**Confirm with traceroute.** Run `traceroute 8.8.8.8` (or `tracert` on Windows) from a device on the network. Under single NAT, hop 1 is your router's private address and hop 2 is already the ISP's public infrastructure. Under double NAT, hops 1 *and* 2 are both private addresses (your router, then the ISP gateway) before public addresses appear at hop 3. Two private hops at the top of the trace is definitive.

## Why double NAT breaks VoIP where single NAT merely strains it

SIP was designed before NAT was universal, and it commits the original sin of embedding transport addresses inside message bodies: the Contact header, the Via chain, and above all the SDP payload that tells the far end where to send audio. NAT rewrites packet headers but does not (correctly) rewrite those embedded addresses, so the far end is handed coordinates that no longer mean anything outside your network. That single-NAT problem, and the STUN/keepalive/rport machinery built to work around it, is covered in depth in [SIP and NAT traversal](/blog/sip-nat-traversal). Double NAT takes each of those failure modes and compounds it.

### Two translation layers, addresses two steps removed from reality

Under single NAT, a phone at 192.168.1.50 advertises that address in its SDP; techniques like STUN let it discover its public address and advertise that instead, and the far end can reach it. Under double NAT the phone's packets are rewritten twice: once by the inner router, once by the ISP gateway. The address the phone can discover with STUN is the *outermost* public address, but the return path now requires two pinholes, one in each NAT, to line up simultaneously, mapped through an intermediate address the phone has no way to see or influence. If either mapping is missing, expired, or symmetric-NAT-scrambled, the audio dies in one direction. This is why [one-way audio](/blog/one-way-audio) is the canonical double NAT symptom: signaling often limps through, the call connects, and then RTP (which flows on separate, dynamically negotiated ports) fails to find its way back through both layers.

### Two timeout clocks, and the shorter one wins

Every NAT device holds UDP mappings only as long as its timeout allows. VoIP survives this by sending keepalives and re-registering often enough to refresh the mapping. Under single NAT you tune against one clock. Under double NAT there are two independent clocks (the ISP gateway might hold UDP mappings for 300 seconds while the inner router gives up at 60, or vice versa) and the shorter timeout governs everything, whether or not you know what it is. ISP gateways are rarely configurable and sometimes use aggressive timeouts of 30–60 seconds.

The symptoms are distinctive. Registrations drop: the phone registers successfully, the shorter mapping expires before the next re-REGISTER, and inbound calls ring straight to voicemail until the phone happens to re-register. Calls die at fixed durations: 30 seconds, 5 minutes, 15 minutes. Always the same number, because a timer, not congestion, is doing the killing. Random network problems fail randomly; expiring timers fail punctually. If your drops are metronomic, read [why calls drop after a set time](/blog/calls-dropping-after-set-time) alongside this post.

### SIP ALG, twice

Here is the kicker. Most consumer and ISP routers ship with SIP ALG enabled, a feature that inspects SIP packets in flight and rewrites the embedded addresses it thinks it understands. Implementations are so chronically buggy that the feature breaks more calls than it fixes, which is why [SIP ALG is the setting that breaks everything](/blog/sip-alg-the-setting-that-breaks-everything) in single-NAT networks too.

Under double NAT, SIP ALG is very often enabled on *both* devices. Your SIP messages get mangled twice, by two different vendors' half-correct rewriting engines, each operating on the other's output. The inner router rewrites the SDP to what it believes is the outside address, which is merely the ISP gateway's private LAN, and then the gateway's ALG rewrites the already-rewritten message again, or fails to because the fields no longer look like it expects. Authentication breaks, Contact headers point nowhere, and the resulting failures are nearly impossible to debug from the endpoints because the corruption happens invisibly in transit. Two NAT layers is a hard problem; two NAT layers with two ALGs is signaling roulette.

## Modem router combo VoIP fixes, ranked

The goal is one NAT layer, no ALG. Here are the paths to it, best first.

### 1. Bridge mode on the ISP gateway (best)

Put the ISP combo unit into bridge mode. This disables its router, NAT, firewall, Wi-Fi (everything except the modem function) and passes the public IP straight to your own router's WAN port. Double NAT is not worked around; it is gone. One translation layer, one timeout clock, one place to disable SIP ALG.

Most cable ISPs support this: Comcast xFi gateways have a bridge mode toggle in the admin interface, and most Spectrum and Cox equipment can be bridged by the ISP on request. Two caveats. First, bridging usually disables the gateway's Wi-Fi and any ISP-delivered extras (some TV and phone services need the gateway routing), so make sure your own router covers those needs. Second, after enabling bridge mode, power-cycle both devices so your router pulls the public IP.

### 2. IP passthrough (AT&T-style gateways)

Some fiber gateways (AT&T's BGW210/BGW320 line is the canonical example) cannot truly bridge because the gateway must stay in the path for authentication. The equivalent feature is **IP passthrough**: the gateway keeps its WAN session but assigns the public IP through DHCP to your router's MAC address, and forwards traffic to it wholesale. Configure it under IP Passthrough with allocation mode "Passthrough" and your router's MAC as the fixed device. Functionally this behaves like bridge mode for VoIP purposes; the gateway still maintains a small internal session table, so it is fractionally less clean than a true bridge, but in practice it resolves double NAT symptoms as completely.

While you are in the gateway's settings, disable its SIP ALG. Passthrough or not, you do not want it inspecting SIP.

### 3. DMZ to the inner router (workable)

If the gateway offers neither bridge mode nor passthrough (or it must keep routing for other services) configure its DMZ (sometimes "DMZplus") to point at your router's WAN address, and give your router a static IP or DHCP reservation on the gateway so the DMZ target never drifts. Now every unsolicited inbound packet reaching the gateway is forwarded to your router, which restores inbound reachability for signaling and media.

Understand what this does and does not fix. Both NAT layers still exist, both timeout clocks still run, and outbound mappings still traverse two tables, so keep SIP registration intervals short (60–120 seconds) to hold both pinholes open. DMZ turns double NAT from broken to survivable; it does not make it single NAT.

### 4. Disable SIP ALG on both layers, regardless

Whichever option above you choose, disable SIP ALG on every device that still routes; and if you are stuck with full double NAT temporarily, disable it on both boxes today, because it is the single highest-value change you can make without touching topology. The setting hides under different names per vendor: SIP ALG, SIP Helper, SIP Transformations, SIP Inspection. Our [router-by-router SIP ALG guide](/blog/sip-alg-router-guide) has the exact steps for the common hardware. On ISP gateways with no visible toggle, bridging or passthrough conveniently takes the ALG out of the path along with the NAT.

One boundary case: if your router's WAN IP is in 100.64.x.x, the second NAT layer is CGNAT inside your ISP and none of these fixes reach it. Ask the ISP for a static or public IP (many sell one for a few dollars a month); for outbound-registering phones to a hosted provider CGNAT is usually tolerable, but anything requiring inbound reachability needs the real public address.

## Verify the fix with a real measurement

Topology changes of this size deserve verification beyond "the phones seem fine now." A phone that registers is not proof the media path is clean: registration is a trickle of small packets, while a call is a sustained 50-packets-per-second stream in both directions, and that stream is what double NAT was silently degrading.

Run a [VoIP quality test](/tools/voip-test) after the change. It pushes real media through your actual network path and measures what a call experiences: latency, jitter, packet loss, and a MOS score, over a full 60-second stream. Run it before the fix if you can, so you have a baseline; run it after, and confirm the numbers hold for the entire duration: a test that degrades or dies partway through is exactly how a surviving NAT timer announces itself. If the post-fix numbers are clean end to end, you have removed one of the most stubborn, least visible causes of VoIP failure there is.

*For the underlying mechanics, read [SIP and NAT traversal](/blog/sip-nat-traversal). For the symptom-side view, see [one-way audio](/blog/one-way-audio) and [calls dropping after a set time](/blog/calls-dropping-after-set-time).*

---

## G.711 vs. Opus vs. G.722: Does Codec Choice Actually Matter?

URL: https://voiptest.com/blog/g711-vs-opus-vs-g722
Published: 2026-09-01
Category: Technical
Tags: codecs, g711, opus, g722, g729, call-quality, mos

Search for VoIP codec comparisons and you will find spec tables: sample rates, bitrates, MOS columns, license notes. What the tables never tell you is the thing you actually want to know: whether picking one codec over another will make your calls sound better, and by how much. The honest answer is more interesting than the tables: sometimes the difference is dramatic and audible in the first second of a call, and sometimes codec choice is a rounding error next to what your network is doing.

This post is the verdict version. We will put the four codecs you will actually encounter (G.711, G.729, G.722, and Opus) head to head, say plainly which one wins each matchup and why, and then draw the line between the situations where codec choice genuinely matters and the ones where it is a distraction from the real problem.

## The difference you can hear: narrowband vs. wideband

Before any head-to-head, one distinction explains most of what people perceive: audio bandwidth, meaning the range of frequencies the codec carries.

Narrowband codecs (G.711 and G.729) sample at 8 kHz and carry roughly 300 Hz to 3.4 kHz. That range was chosen a century ago as the minimum for intelligible telephone speech, and it is why every phone call you have ever made on the PSTN has that unmistakable "phone voice" quality. Consonants like *s* and *f*, which live largely above 4 kHz, get clipped; voices lose their timbre; distinguishing "fifteen" from "sixteen" requires context.

Wideband codecs (G.722 and Opus) sample at 16 kHz or higher and carry 50 Hz to 7 kHz (G.722) or up to 20 kHz (Opus in fullband mode). This is what marketing calls "HD voice." The difference is not subtle. Speech sounds present and natural rather than filtered, listener fatigue on long calls drops measurably, and intelligibility of names, numbers, and spellings improves enough that call centers report fewer repeats. On the [MOS scale](/blog/understanding-mos-scores), narrowband codecs are capped around 4.4 no matter how perfect the network is; wideband codecs can score meaningfully higher on the extended scale because they are reproducing more of the actual voice.

So the first-order answer to "does codec choice matter" is: the narrowband/wideband split matters a lot, and it is the one difference an untrained listener will identify instantly. Everything else is second-order. Now the matchups.

## G.711 vs. G.729: bandwidth savings and what they cost

This is the classic comparison, and it made sense in 2005. G.711 is the PSTN codec: 64 kbps of uncompressed 8-bit audio, negligible CPU cost, near-zero codec latency, and the reference against which everything else is scored. G.729 compresses the same narrowband speech into 8 kbps using a predictive model of human vocal tracts, an 8x reduction in payload.

But the on-wire math is less flattering than the raw bitrates. Every RTP packet carries roughly 40 bytes of IP/UDP/RTP headers regardless of payload. At 20 ms packetization, G.711 costs about 87 kbps per direction on the wire; G.729 costs about 24 kbps. The real saving is closer to 3.6x than 8x, and against a modern connection (even a modest 20 Mbps uplink carries over 200 concurrent G.711 streams) the saving buys you nothing you were short of.

Meanwhile the costs are permanent. G.729's model-based compression caps its MOS around 3.9 versus G.711's 4.4, audible as a slightly synthetic, "underwater" quality on some voices. It handles music, hold tones, and DTMF poorly. It consumes DSP or CPU on every device that encodes it, and if a call gets transcoded G.729-to-G.711 anywhere in the path (common at PSTN gateways), you pay the quality penalty *plus* a lossy re-encode. The patents that once made it a licensed product expired in 2017, which removed the last commercial reason for vendors to keep it in the front of the priority list.

**Verdict:** G.711 wins unless you are on a genuinely constrained link: think satellite, cellular backup, or a WAN circuit shared with everything else and no QoS. G.729 is fading for good reason, and if you are constrained enough to consider it, Opus at a comparable bitrate sounds better anyway.

## G.711 vs. G.722: same bitrate, twice the audio

Here is the comparison with the most lopsided verdict in VoIP. G.722 delivers wideband audio (50 Hz to 7 kHz) at the same 64 kbps as G.711. Same bandwidth cost, same packetization, similar negligible CPU load, and it has been a published ITU standard since 1988. Deployed on two desk phones on the same LAN, the improvement is immediate and obvious: the call sounds like the person is in the room rather than on a phone.

So why isn't everything G.722? Because a call is only as wideband as its weakest hop. The moment a call touches the PSTN, a legacy gateway, or any endpoint that only speaks G.711, it gets negotiated or transcoded down to narrowband. And most business calls touch at least one of those. G.722 thrives inside closed systems: internal calls on a hosted platform, phone-to-phone within one vendor's ecosystem, on-net calls between offices. It evaporates at the borders. There is also mundane friction: devices that support it but ship with it disabled or ranked below G.711 in the default codec list, so it never gets negotiated even between two capable endpoints.

**Verdict:** G.722 wins outright wherever both ends and everything between them support it. There is no bandwidth argument against it; the only thing stopping universal HD voice is the long tail of narrowband infrastructure in the middle of most call paths. If your platform supports it, enable it and rank it first; the fallback to G.711 costs you nothing.

## Opus vs. everything: the codec that assumed the network would be bad

Opus, standardized in 2012 as RFC 6716, is what you get when you design a voice codec after the internet's failure modes are well understood. Where G.711 and G.722 are fixed-rate codecs from an era of engineered telephone networks, Opus assumes the transport is unreliable and adapts.

Three properties set it apart. First, **adaptive bitrate**: Opus operates anywhere from 6 to 510 kbps and can change rate mid-call without renegotiation. When your uplink gets congested, an Opus stream can drop from 40 kbps to 12 kbps and keep the call alive at reduced fidelity; a fixed-rate codec just keeps transmitting into the congestion and loses packets. Second, **in-band forward error correction**: at the cost of some bitrate, each packet carries a low-fidelity copy of the previous packet's audio, so a single lost packet can be reconstructed from its successor rather than concealed by guesswork. Third, genuinely good **packet-loss concealment**: when a packet is unrecoverable, the decoder synthesizes plausible audio from the surrounding speech instead of leaving a gap.

The practical consequence shows up exactly where calls actually fail. At 1% packet loss, G.711 is already producing audible clicks and dropouts; by 3–5% it is objectively poor, with MOS falling toward 3.0 and below. Opus with FEC enabled remains conversational through that same range: listeners often cannot pinpoint the loss at all until it climbs past 5%. We cover the mechanics of why loss hurts fixed-rate codecs so badly in [our guide to VoIP packet loss](/blog/understanding-voip-packet-loss); the short version is that G.711's concealment is primitive and every lost packet is 20 ms of speech gone forever.

Add fullband audio (up to 20 kHz, better than G.722's wideband), open licensing with no patents to negotiate, and the fact that it is the mandatory-to-implement audio codec for browser real-time media (RFC 7874), meaning every browser call, most UCaaS desktop clients, and a growing share of mobile VoIP already use it, and the verdict writes itself.

**Verdict:** Opus wins every matchup on technical merit. It matches or beats every codec here on quality per bit, and it is the only one that actively defends the call when the network degrades. The only reason to run anything else is that some element in your call path doesn't support it, which, in the SIP trunk and desk phone world, is still common.

## The honest verdict: when codec choice matters and when it doesn't

Here is the part the comparison tables omit. On a clean network (sub-1% loss, jitter under 20 ms, reasonable latency) all four codecs deliver calls users rate as good. The gap between G.711 and Opus on a healthy path is real but modest: wideband richness, nothing more. The gap between *any* codec on a healthy path and *any* codec on a degraded one is enormous. A G.711 call over a clean connection beats an Opus call over a congested Wi-Fi link every single time. The network dominates, and no codec rescues a path with 200 ms of jitter or bursty 8% loss.

Codec choice genuinely matters in three situations. **Lossy or variable links** (Wi-Fi, cellular, congested last miles) where Opus's FEC and concealment convert would-be dropouts into calls that merely sound slightly compressed. **Constrained upload bandwidth**, where per-call cost determines how many concurrent calls fit before they degrade each other; the difference between ~87 kbps and ~30 kbps per stream is the difference between 10 and 30 usable channels on the same uplink. **Trunk economics and capacity planning**, where carriers price or provision channels around assumed per-call bandwidth.

Codec choice is a distraction when you are using it to explain quality problems on a path you have never measured. If calls sound bad, the probability that switching G.711 to G.722 fixes it is close to zero; the probability that the cause is loss, jitter, bufferbloat, or a misbehaving router is close to one. Measure first. For a deeper treatment of how encoding decisions ripple into perceived quality, see [how codecs shape call quality](/blog/how-codecs-shape-call-quality).

## The codec you configured is not the codec you get

One more dose of reality. You do not simply *choose* a codec; you express a preference, and the call decides. Every SIP or browser call begins with SDP offer/answer negotiation: the caller lists supported codecs in priority order, the callee picks from the intersection, and every intermediary (PBX, SBC, trunk provider) gets a chance to filter, reorder, or strip that list before the far end ever sees it.

This is why codec configuration so often appears not to work. You rank Opus first on your endpoints; the SBC strips it because its transcoding license doesn't cover it; the trunk offers G.711 and G.729 only; your HD-capable phones dutifully complete a G.711 call. Nothing is broken (every element behaved according to its own configuration) but the codec you chose never had a chance. Transcoding adds another wrinkle: a call can be Opus on one leg and G.711 on another, with a lossy conversion in the middle that costs quality on both. If you want to know what your calls actually negotiate and why, [our SDP media negotiation guide](/blog/sdp-media-negotiation) walks through the offer/answer exchange line by line.

The practical upshot: audit the negotiated codec in a SIP trace or the browser's real-time media internals dump before concluding anything about codec performance, because there is a decent chance your calls are not using the codec you think they are.

## Stop reading tables, start measuring

The interaction between codec and network is exactly the kind of thing that resists intuition and yields to measurement. If you want to build that intuition, our [MOS explorer](/tools/mos-explorer) lets you dial in packet loss, jitter, and latency against different codec profiles interactively and watch the predicted MOS respond; it makes the "Opus degrades gracefully, G.711 falls off a cliff" behavior visible in about thirty seconds.

And for your actual network, run our [VoIP quality test](/tools/voip-test). It sends a real codec-encoded media stream over the path a call would take, not a generic ping, so the loss, jitter, and MOS it reports reflect what a genuine call would experience on your connection. The premium tier adds sequential codec-comparison runs, testing the same path with different codec profiles back to back, which answers the question this entire post circles: on *your* network, with *your* impairments, does the codec matter? Sometimes the answer is yes by half a MOS point. Sometimes it is no, and now you know to go fix the network instead.

---

## SIP 503 Service Unavailable: Causes, Diagnosis, and Fix

URL: https://voiptest.com/blog/sip-503-service-unavailable
Published: 2026-08-28
Category: Troubleshooting
Tags: sip, sip-503, response-codes, troubleshooting, sip-trunking

Of all the SIP failure responses, 503 Service Unavailable is the one that tells you the least on its face and the most once you dig in. A 404 points at a bad number. A 486 points at a busy callee. A 503 says only this: the element that answered cannot process your request right now. Not "the destination doesn't exist," not "you did something wrong," just "not now."

That vagueness is by design. RFC 3261 defines 503 as a temporary condition: the server is overloaded, undergoing maintenance, or otherwise unable to take the call, and the client should treat the failure as transient. But "the server" is doing a lot of work in that sentence, because a SIP request typically crosses three to six elements between your phone and the far end: your PBX, maybe an SBC, your carrier's edge proxy, their core, an interconnect partner's gateway. Any one of them can generate the 503, and each one implies a completely different problem and a completely different fix.

This is the first in a series of deep dives on individual SIP response codes. For the full map of the response-code space, see our [SIP response codes reference](/blog/sip-response-codes); for quick lookups mid-troubleshooting, the [interactive SIP code lookup](/tools/sip-codes) covers every code with its meaning and common causes.

## What SIP 503 Service Unavailable actually means

A 503 is a final response in the 5xx class (server failure) with a specifically temporal meaning: the responding element is currently unable to process the request due to overload or maintenance, and the condition is expected to clear. Two properties follow from that definition, and both matter for troubleshooting.

First, a 503 speaks only for the element that sent it. It says nothing about the destination. The user you are calling may be sitting next to a perfectly working phone; the 503 means one server on the path between you refused to carry the request. This is why proxies that receive a 503 from a downstream server are supposed to try an alternate server if one exists, and why RFC 3261 recommends that a forwarding proxy convert a downstream 503 into a 500 rather than pass it along: the 503 was a statement about one specific server, not about the request. In practice, plenty of proxies forward 503s untouched anyway, which is precisely why you can't assume the code originated at the first hop.

Second, a 503 is supposed to be temporary. When it isn't (when the same call fails with 503 reliably, or every day at 10 a.m.), the code is being used (or abused) to signal something structural: a channel cap, a dead gateway, a route with no working destination. Many PBXs, Asterisk included, return 503 for "I have no usable route or trunk for this call," which is not remotely temporary. Treat the code as a starting point, not a diagnosis.

### Finding which element sent it

Before anything else, identify the source hop. Two places in the response tell you.

The **Via chain** is the reliable one. Every element that forwards a SIP request adds a Via header on top of the stack, and the response travels back down the same chain. In a packet capture, compare the Via headers on your outbound INVITE with those on the 503 that comes back. If the 503 carries only the single Via your phone or PBX inserted, the first upstream hop generated it; the request never went further. If it carries your Via plus your SBC's, the 503 came from beyond the SBC. The response can never contain more Via headers than the request that provoked it accumulated, so the topmost Vias tell you how deep the request got before something said no.

The **Server header** (or occasionally User-Agent on a response) is the convenient one. Many elements identify themselves: `Server: FPBX-16.0.40.7(18.20.0)` is your own FreePBX talking; `Server: kamailio (5.7.2)` on a response from your carrier's IP is their edge proxy. It is optional and sometimes scrubbed by border elements, but when present it can save you the Via arithmetic.

Also look at the **source IP** of the packet carrying the 503 and any **Reason** or custom headers. Carriers frequently add a Reason header (`Reason: Q.850;cause=42`, ISUP "switching equipment congestion") or an X-header naming the internal cause. A 503 arriving from your PBX's own address 2 milliseconds after you sent the INVITE, with no matching request on the WAN side, was manufactured locally, a distinction covered in more depth in our guide to [reading a SIP trace](/blog/reading-a-sip-trace).

## SIP 503 causes: the taxonomy

Nearly every 503 in the wild falls into one of five buckets.

### Trunk capacity and channel limits

The single most common cause on business trunks. SIP trunks are sold with a concurrent-call cap (10, 20, 50 channels), and when every channel is occupied, the next INVITE gets an immediate 503 from the carrier's edge. The signature is unmistakable: calls fail only under load, the 503 arrives fast (the carrier isn't trying anything, it is counting), and failures cluster at your busiest hours. Some carriers use 486 or 480 for this instead, but 503 is the most common choice.

The uglier variant is the cap you didn't agree to. Discount providers routinely oversubscribe their upstream capacity on the assumption that customers won't all call at once; when that assumption fails, some fraction of calls gets 503'd even though no individual customer is over their limit. We cover how this works (and how to detect it) in our post on [VoIP overbooking](/blog/voip-overbooking). The tell: you count your concurrent calls at the moment of failure, you are demonstrably under your contracted channel count, and the 503s still arrive at peak times.

### Server overload

The honest, by-the-book 503: the server is genuinely swamped. On your own PBX this looks like CPU saturation during a call spike, a database connection pool exhausted so the dial plan can't execute, a transcoding load that has eaten every core, or a TLS handshake backlog after a mass phone reboot. On the carrier side it looks like regional congestion, often during genuine mass-calling events. Overload 503s tend to be intermittent, correlate with load metrics, and, from well-implemented servers, carry a short Retry-After.

### Failover and maintenance states

Elements taken out of service deliberately answer 503 on purpose: it is the standard way to tell upstream load balancers "drain me." Carriers doing maintenance park an edge proxy in 503 mode expecting clients to fail over to the next SRV record. If your PBX only ever resolves the first server in the carrier's DNS SRV set (or has a single hardcoded IP), it will sit there collecting 503s from a draining server while a healthy one sits unused. Time-boxed clusters of 503s, often at night, that clear on their own are usually this.

### Upstream gateway failure

The element answering you is fine; the thing *behind* it is not. Your carrier's proxy accepts the INVITE, tries to route it to a PSTN gateway or an interconnect partner, gets no answer or an error, and, having no alternate route, returns 503 to you. These 503s arrive slower (seconds rather than milliseconds, because the proxy actually tried something), frequently carry a Q.850 Reason header, and often affect only certain destinations: calls to one country or one number range fail while everything else works.

### DNS and transport failures behind a proxy

A proxy that cannot even attempt the next hop (DNS resolution for the next domain fails, the TCP connection is refused, the TLS certificate does not validate, or every target in the SRV set is on its blacklist) commonly reports the failure upstream as 503. The same applies locally: a PBX whose trunk registration has lapsed, or whose outbound proxy has stopped resolving, generates its own 503 for every outbound attempt. If every single call fails instantly with 503, check registration state before anything else.

## The Retry-After header

The 503 response may carry a Retry-After header, and when it does, it is the server telling you exactly how it wants to be treated:

```
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP 203.0.113.10:5060;branch=z9hG4bK7f2a
Retry-After: 30
Server: carrier-edge-04
```

Read it as a triage signal. A short value (5, 30, 120 seconds) means transient overload: the server expects to recover and is pacing you. A well-behaved client honors it: it does not retry that server before the interval expires, and if it has alternate targets (from DNS SRV or a configured server list) it fails over to one of those immediately instead of waiting. What clients must never do is hammer retries into a 503: that converts one overloaded server into one collapsing server, which is why some overload-control schemes have servers emit 503 with escalating Retry-After values as load rises.

An absent Retry-After, or an implausibly long one, points structural. A carrier rejecting call 21 on a 20-channel trunk has no recovery estimate to give you: capacity will free up whenever one of your own calls hangs up. A proxy fronting a dead gateway has no idea when the gateway returns. As a rule of thumb: 503 with short Retry-After, wait and retry; 503 without one, start diagnosing.

## Diagnosing a 503: a capture-based walkthrough

Skip the guesswork and go straight to packets. The whole diagnosis usually takes four steps.

**1. Reproduce and capture.** Get a packet capture running where you can see the SIP traffic, on the PBX itself (`sngrep` for live viewing, `tcpdump -w` for a file) or on a mirror port at the edge, and place a failing call. If the failure is intermittent, capture continuously with a ring buffer until it recurs. Capture on both the LAN and WAN interfaces of your PBX or SBC if you can: seeing whether the INVITE ever left the building answers half the question by itself.

**2. Find the 503 and identify the sender.** Open the capture in our [PCAP analyzer](/tools/pcap-analyzer), which extracts the SIP ladder diagram and flags error responses, or filter in Wireshark with `sip.Status-Code == 503`. Now apply the Via test from above: how many Via headers does the 503 carry, what does the Server header say, and what IP did the packet actually come from? You now know whose problem this is.

**3. Check the timing and headers.** A 503 within a few milliseconds of the INVITE means the sender rejected it from local state: a channel counter, a dead trunk flag, a failed route lookup. A 503 after 3–10 seconds means the sender tried a downstream hop and gave up. Note any Retry-After and Reason headers; `Q.850;cause=34` (no circuit available) and `cause=42` (congestion) both scream capacity.

**4. Correlate with local state.** If the 503 is locally generated: check trunk registration status, outbound route configuration, and whether the PBX's own logs show "all circuits busy" or a resolution failure at that timestamp. If it came from the carrier: count your concurrent calls at the failure moment (your CDRs will show it) and compare against your channel cap; note whether failures are destination-specific; and check whether the timestamps line up with your traffic peaks or with a fixed maintenance window.

At the end of this you can say one of three things with evidence: *my PBX never sent the call*, *the carrier rejected it at their edge*, or *the carrier accepted it and failed downstream*. Each has a distinct fix.

## Fixing a 503, by cause

**Capacity: buy channels or fix the routing.** If you are hitting your own contracted cap, the fix is arithmetic: add channels, or move overflow to a second trunk with failover routing so call 21 goes out a different path instead of dying. Also check for routing loops or misconfigured queues that hold channels open longer than they should; a single queue with an aggressive retry policy can eat half a trunk. If you are *under* your cap and still getting busy-hour 503s, you are likely on an overbooked platform, and the realistic fixes are a contractual commitment to dedicated capacity or a better provider.

**Overload on your own PBX: fix the bottleneck.** Correlate the 503s with CPU, memory, and database metrics at the failure timestamps. Common culprits: transcoding that should be offloaded or avoided by aligning codecs end-to-end, a dial plan making synchronous HTTP or database calls per-INVITE, TLS re-handshake storms after network blips, and undersized VMs that were fine at half the current call volume. Registration floods from a fleet of phones rebooting simultaneously deserve special mention: stagger registration intervals.

**Failover and DNS: honor the carrier's redundancy.** Configure your PBX or SBC to resolve the carrier's full DNS SRV record set and fail over on 503, rather than pinning a single IP. If the carrier publishes multiple edge proxies, a 503 from one should cost you one retransmission, not an outage.

**Carrier-side failures: escalate with evidence.** For 503s generated in the provider's network (congestion, dead upstream gateways, destination-specific failures), your fix is their fix, and your job is to make the ticket undeniable. Attach the capture, the exact timestamp with timezone, the Call-ID of a failing call, the source IP that sent the 503, and the Reason header if present. A ticket that says "calls fail sometimes" gets a first-line script; a ticket that says "your proxy at 198.51.100.7 returned 503 with Q.850 cause 42 for Call-ID abc123 at 14:32:07 UTC, 11 concurrent calls on a 20-channel trunk" gets an engineer. If 503s to specific destinations persist, the provider's route to that destination is broken and they need to reroute, something only they can do, but only you can prove.

## Where 503 fits in the bigger picture

A 503 is one code in a large family, and half of effective SIP troubleshooting is knowing which family member you are actually looking at: a 503 that should have been a 486, a 480 masquerading as a capacity problem, a 500 that a proxy politely converted. For the complete map, read our [SIP response codes reference](/blog/sip-response-codes), and keep the [SIP code lookup tool](/tools/sip-codes) open next time you are staring at a ladder diagram. If the 503 turns out to be one symptom among several (audio problems, dropped registrations, one-way calls), start wider with our guide to [common SIP problems](/blog/common-sip-problems). And if you are provisioning trunks and want to understand the capacity model you are buying into before the busy-hour 503s start, our [SIP trunking guide](/blog/sip-trunking) covers channel sizing from the ground up.

---

## VoIP Over Starlink: What Works, What Breaks, and How to Fix It

URL: https://voiptest.com/blog/voip-over-starlink
Published: 2026-08-25
Category: Technical
Tags: starlink, cgnat, satellite-internet, nat-traversal, jitter, rural-voip

The [2026 copper shutdown](/blog/pots-copper-shutdown-2026) is doing something the satellite industry spent decades failing to do: making satellite the default phone line for a large slice of rural America. As carriers retire POTS lines in areas where fiber will never be trenched and cellular coverage is a rumor, the practical replacement for a landline is increasingly a VoIP service running over a Starlink dish. What used to be an enthusiast question (*can I run a softphone over satellite?*) is now the mainstream question a lot of households and small businesses are asking, often with no other option on the table.

The short answer is that VoIP over Starlink mostly works, and works far better than anyone with memories of older satellite internet would expect. But it fails in specific, predictable ways, and almost all of them trace back to two facts about the service: the constellation hands your connection between satellites every fifteen seconds, and Starlink puts you behind carrier-grade NAT. Understand those two things and you can fix nearly everything that goes wrong.

## Why Starlink is not your father's satellite internet

If your mental model of satellite voice comes from GEO services (HughesNet, Viasat, the dishes bolted to farmhouses since the 2000s), throw it out. Geostationary satellites park 35,786 km above the equator, and physics collects the toll: a round trip of roughly 600 ms before a single router has queued a packet. At that latency, conversation collapses into walkie-talkie turn-taking. The ITU's guidance puts one-way delay above 400 ms as unacceptable for interactive voice, and GEO blows through it before your traffic reaches the ground station. We cover that world in our [satellite internet](/blog/satellite-internet) guide; it remains true for GEO.

Starlink's satellites orbit at around 550 km, sixty-five times closer. Typical round-trip latency lands between 25 and 60 ms, which is not just usable for voice, it is comparable to many terrestrial cable connections. Latency, the historic satellite dealbreaker, is simply solved. If you want the deeper background on why latency and its variation matter for calls, see [what jitter is and why it matters](/blog/what-is-jitter-and-why-it-matters).

What LEO gives you instead is a distinctive *jitter* profile. Each satellite is only overhead for a short arc, so your dish re-targets to a new satellite roughly every 15 seconds; the constellation schedules handoffs on a global 15-second frame. Each handoff changes the physical path length, and the switch itself can drop or delay a handful of packets. On a graph, Starlink jitter doesn't look like the gentle noise of a congested DSL line; it looks like a calm baseline of 5-15 ms punctuated by sharp spikes of 30-80 ms (occasionally worse) arriving with eerie regularity, plus brief micro-outages of a few hundred milliseconds when a handoff goes badly or an obstruction blocks the new satellite's sightline.

For a codec receiving a packet every 20 ms, that pattern is survivable but demanding. A well-implemented adaptive jitter buffer rides through the spikes with a barely perceptible stretch in the audio. A shallow, fixed jitter buffer (common in older ATAs and cheap hardware phones) discards the late packets instead, and the user hears a small glitch or syllable clip every fifteen seconds. If someone tells you their Starlink calls "stutter on a rhythm," this is exactly what they are describing, and the fix is usually a device or provider whose jitter buffer adapts, not a support ticket to Starlink.

Packet loss behaves similarly: fractions of a percent on average, but concentrated into bursts around handoffs and weather rather than spread evenly. Averaged statistics will tell you the link is nearly perfect; your ears will occasionally disagree. This is why measuring the distribution matters more than measuring the mean; more on that at the end.

## The CGNAT problem: no public IP, no port forwarding

The bigger structural issue is invisible on any speed test. Standard Starlink service (residential and roam plans) places every customer behind carrier-grade NAT. Your router gets an address out of the 100.64.0.0/10 shared address space, and the public IPv4 address your traffic exits from is shared with a crowd of other subscribers and can change without notice. Two consequences follow immediately:

- **You cannot port forward.** There is no port on that shared public IP that belongs to you, so there is nothing to forward and no menu to do it in. Every guide that says "just forward UDP 5060 and your RTP range" is a dead end on Starlink.
- **Nothing on the internet can initiate a connection to you.** Inbound packets that don't match an existing outbound flow are dropped at Starlink's ground infrastructure before they ever reach your dish.

SIP was built assuming endpoints could be reached, so CGNAT hits it in several places at once. The general problem (SIP embedding private addresses inside message bodies where NAT can't rewrite them) is covered in depth in [SIP and NAT traversal](/blog/sip-nat-traversal); CGNAT adds two aggravations of its own.

First, the NAT state timeouts are not yours to configure. On your own router you can set generous UDP timeouts; on Starlink's CGNAT you get what you get, and observed UDP mappings can expire after as little as 30-60 seconds of silence. A phone that registers with a typical 3600-second expiry and then goes quiet will have its NAT mapping evaporate long before the next re-REGISTER. The registration still *looks* valid on both ends, but the return path is gone, so the next inbound call's INVITE dies at Starlink's edge and the caller goes to voicemail while your phone sits silent. This is the classic "outbound calls work, inbound calls don't" complaint, and on Starlink it is nearly always this mechanism. Our [SIP registration](/blog/sip-registration) explainer walks through why the expiry-versus-NAT-timeout race works this way.

Second, RTP has the same problem independently. Even when signaling survives, the media stream needs its own pinhole, and a call where one side is momentarily silent (hold music the other direction, a long listen) can idle the mapping out mid-call. Result: audio that dies in one direction partway through an otherwise connected call.

### The fixes, in order of preference

**Aggressive registration and keepalives.** Set registration expiry to 60-120 seconds instead of the customary 3600. Enable whatever keepalive your device offers (SIP OPTIONS pings, CRLF keepalives, or STUN binding refreshes) at a 20-30 second interval, below the shortest CGNAT timeout you might encounter. On the media side, enable symmetric RTP (send media back to the address packets actually arrive from, ignoring the SDP) on any equipment you control, and RTP keepalives or comfort-noise packets so the media pinhole never idles. For most hosted-seat users, this paragraph is the entire fix.

**Outbound-registration architectures.** The clean structural solution is to never need inbound reachability at all. Hosted VoIP seats already work this way: the phone opens the connection outward to the provider's session border controller, keepalives hold it open, and inbound calls ride the existing flow back down. This is why cloud phone service on Starlink mostly just works. If you run your own PBX, the same principle applies: configure trunks as outbound registrations to your ITSP rather than IP-authenticated trunks that expect the carrier to connect inward, and prefer SIP over TCP or TLS where offered, since TCP connections tend to hold CGNAT state longer and more predictably than UDP.

**A tunnel or an SBC-terminated trunk.** When you genuinely need a stable public address (an on-prem PBX taking IP-authenticated inbound trunks, or remote-worker phones registering *to* your PBX), put the public edge somewhere else. A WireGuard or IPsec tunnel from your PBX to a small cloud VM gives you a public IP that CGNAT can't touch, at the cost of a few milliseconds and a VM bill. A step up in polish is terminating the trunk on a cloud-hosted SBC or SBCaaS instance that holds the carrier-facing edge, with your PBX connecting outward to it. And Starlink itself sells an escape hatch: the Priority (business) tier offers a public IPv4 option, which restores ordinary port-forwarding at your own router and dissolves the whole category of problem (worth pricing before you engineer around it).

## What genuinely breaks vs. what's fine

**Fine, essentially out of the box:** hosted and cloud VoIP seats: the provider's edge does the NAT heavy lifting, your phones only ever connect outward, and Starlink's latency is a non-issue. Softphones and mobile VoIP apps, which were built for hostile NAT from day one. Outbound-registered trunks from a PBX to an ITSP, with the keepalive tuning above.

**Fine with attention:** anything with a fixed jitter buffer or decade-old ATA firmware, which will audibly flinch at handoff spikes until replaced or reconfigured. Fax over IP, marginal on every network, is actively bad over handoff-induced loss bursts; if you still must fax, use a cloud fax service rather than T.38 over the dish.

**Genuinely hard:** an on-premises PBX that needs to *receive*: inbound IP-authenticated trunks, remote extensions registering in, anything requiring an open listening port. Behind standard Starlink this does not work and cannot be made to work with router settings, because the blocking NAT isn't in your building. Your options are the ones above: restructure to outbound registration, tunnel to a public IP, put an SBC in the cloud, or pay for the Priority plan's public IPv4. Pick one deliberately; duct-tape approaches like relentless re-registration alone tend to produce a system that works until the CGNAT mapping shifts, then mysteriously doesn't.

Two local factors deserve a check regardless of architecture. First, obstructions: even a few percent sky blockage from a tree line concentrates its damage into exactly the micro-outages that voice notices most, so clear the dish's field of view before blaming anything else. Second, bufferbloat: Starlink uplink is modest (usually 10-30 Mbps), and a large upload (cloud backup, a video call's screen share) can queue voice packets behind it for hundreds of milliseconds. A router with smart queue management (CAKE or fq_codel) in front of the Starlink unit keeps voice latency flat under load and is one of the cheapest audible upgrades available.

It is also worth saying plainly: none of this is Starlink being hostile to VoIP. CGNAT is the reality on most modern ISPs that have run out of IPv4; many [fixed wireless](/blog/fixed-wireless) and cellular providers do exactly the same thing. Starlink just happens to be arriving in a lot of homes at the exact moment the copper phone line leaves.

## Measure the link you actually have

Everything above describes the typical Starlink profile, but your dish is not typical: it has your obstructions, your cell's congestion, your weather. Before you commit a business phone system to the link, or while you're diagnosing that once-every-fifteen-seconds stutter, measure it. The [free VoIP test](/tools/voip-test) sends a real encoded media stream over the path a call would take, and reports jitter, packet loss, latency, and a MOS score: the same numbers a call would experience, not a raw bandwidth figure that hides everything interesting.

One run tells you the baseline. The Starlink-specific move is to run it several times across an hour: handoff behavior, obstruction dropouts, and evening congestion all show up as run-to-run variation that a single test can't catch. If jitter stays under about 30 ms and loss under 1% across repeated runs, voice will be solid with any competent provider. If you see periodic spikes, you now know they're the handoff rhythm, and you know from this post exactly which knobs to turn.

---

## Microsoft Teams Call Quality: Prove Whether It's Actually Your Network

URL: https://voiptest.com/blog/microsoft-teams-call-quality-network
Published: 2026-08-21
Category: Troubleshooting
Tags: microsoft-teams, call-quality, troubleshooting, jitter, packet-loss, remote-work

Teams tells you the call quality is poor. It might even flash the little banner: "Poor network quality detected." What it will not tell you is *where* the problem is: your laptop, your Wi-Fi, your router, your VPN, your ISP, the office firewall, or Microsoft's own infrastructure. The blame lands on "your network" as if that were a single thing, and you are left rebooting the router because it is the only network object you can physically touch.

This post is about turning that vague accusation into a specific, testable claim. Teams call quality issues are almost always locatable if you know which numbers to read and how to isolate the variables. By the end you should be able to say "the problem is jitter on the Wi-Fi leg" or "the problem is the VPN concentrator" or, occasionally, "the problem is Microsoft, and here is the evidence", instead of "Teams is bad today."

## Your internet is fast. That was never the question.

Start with the most common dead end. A user complains about choppy Teams audio, someone runs a speed test, it reports 500 Mbps down, and the conclusion is that the network is fine. The conclusion does not follow, and understanding why saves hours of misdirected troubleshooting.

A Teams audio call consumes roughly 60-100 kbps in each direction. That is about 0.02% of a 500 Mbps connection. Bandwidth is not scarce and has not been scarce for voice since the DSL era. What voice needs is *delivery discipline*: a packet every 20 milliseconds, arriving in order, on schedule, every single time, for the entire call. A connection can move gigabytes effortlessly while failing this test constantly, because throughput and timing are different properties of a network. We cover the mechanics in [bandwidth doesn't mean quality](/blog/bandwidth-doesnt-mean-quality), but the operational takeaway is simple: a speed test result is not evidence about call quality in either direction. Stop running them for this problem.

The three numbers that actually predict Teams call quality are latency (how long packets take to cross the path), jitter (how much that time varies packet to packet), and packet loss (how many never arrive). Every symptom users report (choppy audio, robotic voices, audio cutting out, talking over each other) maps to one of these three. If you want the full symptom-to-metric mapping, see our guide to [latency, jitter, and packet loss](/blog/latency-jitter-packet-loss-details).

## Reading Call Health like it matters

Teams ships a live diagnostic that most users never open. During any call, click the **More** (three dots) menu and select **Call health**. You get a real-time panel showing, for the leg between your client and Microsoft's media edge: round-trip time, jitter, packet loss, and the codec bitrate in use, broken out for audio, video, and screen share.

Here is how to read it. Microsoft's published performance targets for the client-to-edge leg are:

- **Packet loss under 1%** averaged over the call. Below 0.5% you will rarely hear anything. Between 1% and 3% you get audible dropouts and the smeared, underwater artifacts of a codec concealing missing frames. Above 3% sustained, the call is genuinely bad and everyone knows it.
- **Jitter under 30 ms.** The jitter buffer in the Teams client can absorb variation up to a point by delaying playback; past roughly 30 ms it must choose between adding perceptible delay and discarding late packets, and either choice degrades the call. Jitter is the usual culprit behind [choppy or robotic audio](/blog/choppy-robotic-audio), more often than loss, in our experience.
- **Round-trip time under 100 ms is Microsoft's target; treat 200 ms as the trouble line.** Between 100 and 200 ms, conversation still flows. Above 200 ms RTT, the acoustic gap between one person finishing and the other starting gets long enough that humans start talking over each other, then both stop, then both start again. The audio itself can be pristine and the call still feels broken.

Two practical notes. First, watch Call health *while the problem is happening*. These numbers move: jitter that averages 12 ms can spike to 80 ms for the ten seconds your audio fell apart, and a glance afterward will show you nothing. Second, remember what leg you are measuring: Call health shows your client to Microsoft's edge. The other participant has their own leg with its own numbers. If your panel is clean and the caller still sounds terrible, the problem is on *their* side or beyond the edge, which is diagnostic gold, because you have just cut the search space in half.

Admins have a wider lens: the Call Quality Dashboard and per-user call analytics in the Teams admin center retain these metrics per call, per leg, including the far end. If one user reports problems, pull their last ten calls and look for the pattern before touching any hardware.

## Why Teams audio cuts out: isolating the fault domain

"Audio cutting out" is a symptom with at least six possible homes: the device, the Wi-Fi link, the LAN, the ISP path, the far-end participant, or Microsoft. The way to find which one is not intuition; it is controlled A/B comparison, changing exactly one variable at a time. This is the same discipline we describe in [diagnosing VoIP problems](/blog/diagnosing-voip-problems), applied to the Teams stack.

### Wired vs. Wi-Fi

The single highest-yield test. Plug the machine into Ethernet, reproduce the call, watch Call health. If jitter drops from 45 ms to 4 ms and the dropouts vanish, you have found the fault domain: the wireless link. Wi-Fi is the number one source of jitter in home and small-office Teams calls: retransmissions, channel contention, a microwave oven, a neighbor's access point, or simple distance from the AP all show up as timing chaos that voice cannot tolerate. The details, and what to do about them, are in [wired vs. Wi-Fi for VoIP](/blog/wired-vs-wifi-for-voip). If the problem persists on Ethernet, Wi-Fi is exonerated and you move one hop out.

### VPN on vs. VPN off

Corporate VPNs are the second great destroyer of Teams calls. [A full-tunnel VPN](/blog/voip-over-vpn) forces your media through the VPN concentrator (often in a data center hundreds of miles away) before it ever reaches Microsoft, adding latency, adding jitter, and frequently forcing the media into TCP encapsulation, which is poison for real-time audio. Run the same call with the VPN connected and disconnected and compare Call health. If RTT falls from 180 ms to 40 ms with the tunnel down, the fix is split tunneling: Microsoft explicitly recommends excluding Teams media traffic (UDP ports 3478-3481 toward Microsoft's ranges) from the VPN. This is a configuration change your IT team can make in an afternoon, and it is one of the most common root causes for remote workers, a topic we cover more broadly in [VoIP quality for remote teams](/blog/voip-quality-for-remote-teams).

### One user vs. the whole office

Scope tells you altitude. If one person on the office network has bad calls and twenty others are fine, the problem lives close to that person: their machine, their headset, their cable, their switch port, their Wi-Fi position. (Do not skip the device layer: a USB headset with a failing cable or a laptop pinned at 100% CPU produces symptoms indistinguishable from network loss.) If *everyone's* calls degrade, the problem lives in shared infrastructure: the firewall, the internet uplink, the ISP. Congested uplinks are a classic office pattern: voice is fine until someone starts a large upload, the uplink queue fills, and every Teams call in the building develops 100 ms of jitter simultaneously. That signature, correlated degradation across users, points at the shared edge, and the fix is QoS or more uplink, not new headsets.

### Morning vs. afternoon

Time-of-day correlation is a fault-domain signal people overlook. Calls that are clean at 8 a.m. and choppy from 2 p.m. to 5 p.m. indicate congestion somewhere on the path that follows load: the office uplink during business hours, or residential ISP contention in the evening for remote workers. Run the same test call at both times and keep the Call health numbers. A path that degrades on schedule is a capacity problem, not a configuration problem, and the schedule tells you whose capacity.

Worked through in order (wired vs. wireless, VPN on vs. off, one user vs. many, quiet hours vs. busy hours), these four comparisons locate the overwhelming majority of Teams call quality issues to a specific fault domain in under an hour, without opening a single support ticket.

## When it actually is Microsoft

It happens. Microsoft runs one of the largest real-time media networks on earth, and it still has incidents: regional media relay degradation, transport outages, bad client builds. The base rate is low; the overwhelming majority of poor calls trace to the first-hop network. But "it's never Microsoft" is as wrong as "it's always Microsoft," so here is how to tell.

The signature of a Microsoft-side problem is **correlated failure across uncorrelated networks**. If your home-office user on Comcast, your headquarters on fiber, and your contractor on a different continent all report degraded Teams calls in the same window, no shared local cause can explain it. Confirm with three checks:

1. **Service health.** Check the Microsoft 365 service health dashboard (admin center, or the @MSFT365Status feed) for a Teams advisory. Incidents frequently show up there within the hour, though not always immediately.
2. **Your own leg's numbers.** Open Call health during a bad call. If your RTT, jitter, and loss to Microsoft's edge are all comfortably inside the thresholds (sub-50 ms RTT, sub-15 ms jitter, near-zero loss) while the call still sounds broken, the degradation is happening beyond the edge, inside infrastructure you cannot see and do not control.
3. **An independent path measurement.** Run a [VoIP quality test](/tools/voip-test) from the affected machine at the moment of the problem. If an independent real-time media path from the same machine over the same network measures clean, you have two witnesses agreeing that your network is delivering packets on time. The variable that remains is the service.

When all three line up, stop troubleshooting your network. Document the timestamps and the clean measurements, file the ticket or wait out the incident, and, importantly, show the evidence to the users who are convinced it is the office Wi-Fi again.

## Prove it with numbers, not vibes

The deeper problem with troubleshooting Teams by feel is that Teams is both the patient and the only witness. Its Call health panel is genuinely useful, but it only reports during a Teams call, only for the Teams path, and only while you remember to look. What you want is an independent measurement of the same network path, taken outside Teams entirely, that you can run on demand and compare over time.

That is what our [free VoIP quality test](/tools/voip-test) is for. It runs in the browser (no install, no account) and sends real encoded audio over an actual media path for 60 seconds, measuring jitter, packet loss, latency, and a MOS score for the path your calls actually traverse. Run it wired, then on Wi-Fi. Run it with the VPN up, then down. Run it at 9 a.m., then at 3 p.m. Each result is a shareable report you can hand to IT, your ISP, or your own skeptical memory.

If the test comes back with 8 ms jitter, 0% loss, and a MOS of 4.3 while Teams is complaining about your network, you have proof the accusation is false; escalate accordingly. If it comes back with 60 ms jitter on Wi-Fi and 5 ms on Ethernet, you have your answer without touching a Teams setting. Either way, you have replaced "poor network quality detected" with a number, a location, and a next step. That is the entire game.

---

## Why DTMF Breaks on VoIP, and the Three Ways to Send It

URL: https://voiptest.com/blog/dtmf-over-voip
Published: 2026-08-19
Category: Technical
Tags: dtmf, rfc-2833, sip-info, rtp, troubleshooting, voip

The complaint arrives in a specific shape. Calls connect. Audio is clean in both directions. People can talk for an hour without issue. But when someone dials into the conference bridge and types the access code, nothing happens. Or the bank's IVR keeps saying "I didn't catch that." Or the voicemail system ignores the PIN.

Nothing is wrong with the audio path, which is why the usual diagnostics come back clean. The problem is that a keypress is not audio. Or rather, it stopped being audio somewhere around 2001, and there are now three different ways to carry one, and both ends of the call have to have chosen the same one.

## The problem underneath

DTMF stands for Dual-Tone Multi-Frequency, and the name describes the original mechanism exactly. Press 5 on an analog phone and it generates two sine waves simultaneously: 770 Hz and 1336 Hz. Every digit is a unique pair drawn from four row frequencies and four column frequencies. A detector on the far end listens for that pair and knows which key you pressed.

This design was excellent for the network it was built for. An analog circuit carries whatever audio you put on it, faithfully, end to end. The tones arrive as the tones you sent.

VoIP breaks that assumption in a way that is easy to miss, because it breaks it selectively.

The moment audio is compressed, it stops being a faithful reproduction and becomes a *reconstruction*. G.711 is waveform coding: it samples the signal and sends the samples, so a DTMF tone comes out roughly the way it went in. But low-bitrate codecs work completely differently. They carry a model of human speech: parameters describing a vocal tract, an excitation signal, a pitch. The decoder rebuilds something that sounds like the original to a human ear.

DTMF tones are not speech. They are two pure sine waves, which is close to the worst possible input for a codec built around a model of the human voice. What comes out the far end may still sound like a beep to you while being distorted well past what a detector will accept. The digit is, functionally, gone.

This is why inband DTMF has the most confusing failure signature in VoIP. It works fine, until a call negotiates a different codec, and then it doesn't, and nothing else about the call changed.

## Method one: inband

Inband DTMF is the original approach carried forward unchanged. The tones are generated as audio and travel inside the [voice stream](/blog/how-codecs-shape-call-quality) along with everything else. No signalling, no negotiation, no separate mechanism. If the audio arrives, the tones arrive.

**When it works:** on G.711 end to end, with no transcoding anywhere in the path. Toll-quality uncompressed audio reproduces the tones well enough for reliable detection.

**When it fails:** whenever a compressed codec is involved, and whenever [packet loss](/blog/understanding-voip-packet-loss) clips the tone. There is a subtler failure too: packet loss concealment. When a packet goes missing mid-tone, the decoder invents plausible audio to fill the gap. That is exactly right for speech and exactly wrong for a tone, because the invented audio may extend the tone, break it into two shorter tones, or shift its frequency content. A single press can be detected as two, or as nothing.

Inband is not something you should choose today. It is something you should recognise when you inherit it.

## Method two: RFC 2833 / RFC 4733 telephone-events

This is the method that solved the problem, and it is what almost everything uses now.

Instead of sending the sound of a keypress, the sender describes the keypress as data: *the user pressed 5, it has lasted this long, at this volume.* That description travels in the RTP stream alongside the audio, but in its own payload type, so it is never handed to the codec at all. Nothing gets compressed, so nothing gets mangled.

You will hear this called RFC 2833 almost universally. RFC 2833 was obsoleted by **RFC 4733** in 2006, with RFC 4734 covering tones more broadly, but the old number stuck in vendor documentation and in conversation. When someone says "2833," assume they mean telephone-events in general.

The events themselves are simple. Digits 0 through 9 are events 0 through 9. `*` is 10, `#` is 11, and the rarely-used A through D keys are 12 through 15. Each event packet carries the event code, a volume, a duration, and an end bit. Because a keypress has a duration, the sender emits a series of packets as the key is held, then marks the final packet with the end bit, usually sending that final packet three times, since losing the end marker is worse than sending it redundantly.

**How it gets negotiated** is where the failures start. Telephone-event uses a *dynamic* payload type, meaning the number identifying it is not fixed by the standard; it is chosen per call, from the 96–127 range, and announced in the [SDP](/blog/sdp-media-negotiation):

```
m=audio 49170 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
```

That says: this call carries G.711 µ-law as payload type 0, and telephone-events as payload type 101, supporting events 0 through 15. Payload type 101 is a near-universal convention, which is a blessing right up until you meet a device that picks 96, or 100, or 127.

Each side advertises the number it wants to *receive*. A correct implementation reads the far end's SDP and sends events using the far end's number. An implementation that assumes 101 because 101 is what everyone uses will send events the far end does not recognise. And because the packets are still valid RTP, nothing errors. They are simply ignored.

## Method three: SIP INFO

The third method abandons the media path entirely and sends keypresses as SIP requests in the signalling channel:

```
INFO sip:bob@192.168.1.100:5060 SIP/2.0
CSeq: 5 INFO
Content-Type: application/dtmf-relay
Content-Length: 22

Signal=5
Duration=250
```

It works, and it has one real advantage: it is completely immune to anything that happens to the audio. Codecs, packet loss, and transcoding cannot touch it.

It also has two problems that keep it a fallback rather than a default.

The first is that **there is no single standard for the body**. `application/dtmf-relay` in the format above is a Cisco convention that became a de facto standard; `application/dtmf` exists too, with a different body; some implementations use neither. Two devices can both "support SIP INFO" and still fail to understand each other.

The second is timing. Media and signalling take different paths through the network, and often through different intermediaries. A digit sent as an INFO can arrive noticeably out of step with the audio around it: usually harmless for an IVR menu, occasionally a real problem for anything time-sensitive, like DTMF-controlled recording or a system that expects digits to align with prompts.

Use SIP INFO when a path genuinely will not carry telephone-events. Do not use it as a first choice.

## How it actually fails

The failures are recognisable once you know the shapes.

| Symptom | Usual cause |
|---|---|
| IVR ignores every keypress | Method mismatch. One end sends telephone-events, the other listens inband, or vice versa |
| Digits register twice (pressing 1 gives 11) | Two methods active simultaneously. The device sends inband *and* telephone-events; the far end detects both |
| Works internally, fails to outside numbers | Your PBX and phones agree with each other. The carrier expects something else. Classic trunk-side mismatch |
| Worked yesterday, broken today, nothing changed | A codec changed. Inband DTMF that was riding on G.711 met a call that negotiated something compressed |
| Digits occasionally dropped under load | Packet loss on RTP events, or an end bit lost so a press never terminates cleanly |
| One long press becomes several digits | Duration and end-bit handling. Either the sender is not marking the end, or a middlebox is regenerating events |
| Works one direction only | Each side advertises what it can receive. The two directions are negotiated separately and can disagree independently |

That last one deserves emphasis, because it is the most confusing in practice. Outbound digits working while inbound digits fail is not a contradiction: it is two independent negotiations, one of which succeeded.

## Diagnosing it

The good news is that DTMF problems are unusually easy to confirm from a [packet capture](/blog/what-packet-capture-tells-you), because the evidence is unambiguous.

**Read the SDP on both sides first.** Look at the `m=audio` line and the `a=rtpmap` entries in the INVITE and in the answer. Is `telephone-event` offered by both? Do both sides list the *same* payload type number for it? A mismatch here explains everything and takes ten seconds to spot.

**Then look at what is actually in the RTP.** If both sides negotiated telephone-event as 101, filter for RTP packets with payload type 101 while someone presses keys. Three outcomes: events are present and correctly numbered, meaning the problem is at the far end's detector; events are present with the *wrong* payload type, meaning the sender ignored the negotiated number; or there are no events at all, meaning the sender is not using the method it agreed to.

**Check for INFO messages** in the signalling. If digits are arriving as SIP INFO while the far end is watching RTP, you have your answer.

**Then the field test that needs no capture at all:** force the call to G.711 and try again. If digits start working, you were sending inband and a codec was destroying them. That single test separates the codec-related failures from the negotiation-related ones, and it takes a minute.

Our [PCAP analyzer](/tools/pcap-analyzer) will pull the SIP dialogs and RTP streams out of a capture and map them to each other, which makes the SDP-versus-actual-RTP comparison quick. For narrowing a large capture to the call in question first, see [how to find the failing call in a huge SIP trace](/blog/reading-sip-traces-without-losing-your-mind).

## What to standardise on

**Use RFC 4733 telephone-events everywhere.** It is codec-independent, it is what carriers expect, and it is the only method with a real standard behind its wire format. Every modern endpoint supports it.

**Send exactly one method.** The double-digit problem is entirely self-inflicted. Many devices ship configured to send inband *and* telephone-events on the assumption that redundancy helps. It does not; it produces duplicates on any far end that listens for both.

**Honour the payload type the far end advertised** rather than assuming 101. If you are choosing equipment, this is worth testing explicitly, because it is a common enough bug that it is worth knowing about before deployment rather than after.

**Let an SBC do the translation when you cannot control both ends.** DTMF interworking is one of the standard jobs a [session border controller](/blog/sbc-fundamentals) does: accept telephone-events from your PBX, emit SIP INFO to a carrier that requires it, and keep both sides unaware of the other's preference. If you are already running one for trunk termination, this is a configuration line rather than a project.

**Test the path you actually use.** DTMF working between two desk phones on the same PBX proves very little about DTMF working into your carrier's IVR. The interesting failures live at boundaries: trunk handoffs, transcoding points, anything that rebuilds the media stream. If you are mapping call flows through menus and queues, the [IVR planner](/tools/ivr-planner) is a useful way to see where those boundaries sit before you start testing.

---

*DTMF is one of several things that work perfectly until a call crosses a boundary and something re-encodes it. For the wider category, see [Common SIP Problems and What They Look Like](/blog/common-sip-problems), or the [SIP Signaling From the Wire Up](/blog/series/sip-signaling-from-the-wire-up) series for how the negotiation underneath all of this works.*

---

## Most Free VoIP Tests Don't Test VoIP

URL: https://voiptest.com/blog/most-voip-tests-dont-test-voip
Published: 2026-08-18
Category: Industry
Tags: voip-test, speed-test, jitter, packet-loss, mos, testing-methodology

Search for "VoIP test" and run the top results. Watch what actually happens during each one (the network tab in your browser's developer tools is enough). In most cases you will find that no voice-shaped traffic ever flows. The page is a marketing asset wrapped around a much simpler measurement: a speed test, a loop of timed web requests, or a port reachability check, presented with a score and a call to action.

That's not an accusation of bad faith. Most of these tools are honest about their mechanics if you read carefully: the caveats are in the fine print, the "advisory" labels are there. But the category as a whole has trained people to believe they've tested their voice quality when what they've tested is something else. This post is a field guide: what's actually behind the tests you'll find, why the differences matter, and the questions that reveal which kind you're looking at.

## The four things sold as a VoIP test

**The rebadged speed test.** Download streams, upload streams, a ping, and a verdict like "your connection is VoIP ready." Throughput is the one metric voice barely needs: a G.711 call uses roughly 87 Kbps per direction, so a connection with 500 Mbps of headroom can still [sound terrible](/blog/bandwidth-doesnt-mean-quality) if its timing is inconsistent. A speed test measures how much data moves. Voice quality depends on how *consistently* small packets arrive, which bulk TCP transfers cannot tell you.

**The HTTP timer.** This one looks more like a diagnostic: it reports latency, jitter, sometimes packet loss. But the traffic behind the numbers is a loop of web requests. "Latency" is the round trip of an HTTP exchange, including server processing and browser overhead. "Jitter" is the variance of that loop, and application-path variance routinely measures tens to hundreds of milliseconds on a network whose actual packet-level jitter is under five. "Packet loss" is the giveaway: check the sample count. A test that reports loss across ten or twenty probes can only detect a catastrophically broken network. One percent loss, the level that's already audible on a call, is statistically invisible in a ten-sample window. You need thousands of packets in the denominator before a loss percentage means anything, which is what a real media stream provides and a probe loop does not.

**The reachability check.** The most sophisticated of the three: it gathers connectivity candidates, probes UDP paths, sometimes attempts relay allocations against SIP-style and RTP-style ports, and reports firewall readiness or a SIP ALG signal. To be clear, this is genuinely useful: a blocked UDP path or a [misbehaving SIP ALG](/blog/common-sip-problems) will absolutely break a deployment, and knowing before install day beats discovering it after. But a reachability check is a *firewall* test, not a *quality* test. It answers "can packets get through?" and says nothing about what happens to them on the way: no jitter under sustained load, no loss rate, no timing distribution. And the SIP ALG part deserves particular skepticism, which gets its own section below.

**The real media-path test.** The rare kind: the test establishes an actual media session and sends a continuous stream with voice codec encoding, real packet sizing, and real pacing (the same traffic shape as a phone call), then measures every packet. Jitter means the interarrival variation of paced voice packets. Loss has thousands of packets in the denominator. Latency is the round trip of the media path itself. This is the only category whose numbers describe what a call will experience, because it's the only category that sends what a call sends.

## Why browser SIP ALG "detection" is inference, not detection

SIP ALG is a firewall feature that rewrites SIP signaling as it crosses NAT, and it breaks things constantly: registration loops, [one-way audio](/blog/one-way-audio), dropped calls. A test that could reliably flag it would be valuable. The problem is what a browser is physically able to observe.

Detecting an ALG means catching it rewriting packets: send SIP-shaped payloads through the firewall, compare what arrives against what was sent, and diff the mangled headers. A browser cannot do this. It has no raw UDP sockets, so it cannot emit actual SIP traffic on port 5060. The media streams it *can* send are encrypted end to end, so an ALG can neither read nor rewrite them, which also means the test can't observe interference that isn't there to observe. What's left is indirect evidence: UDP toward a SIP-style port fails while other UDP paths succeed, which is *consistent with* an ALG or a port-specific firewall rule, and equally consistent with several other things.

So when a browser test reports a SIP ALG result, it is reporting an inference from port reachability, whatever the label says. The honest phrasing is "the SIP port looks filtered; verify with a handset," and some tools do hedge exactly that way once you read past the headline. A definitive answer requires a device that actually speaks SIP on the network in question: a handset or softphone, registered against the real service.

## Five questions that reveal what a test measures

1. **What traffic flows?** Open the developer tools and watch. Bulk transfers mean a speed test. A burst of small web requests means an HTTP timer. A short flurry of connectivity checks and nothing else means a reachability check. A sustained stream of small, evenly spaced packets for the duration of the test means voice-shaped media actually flowed.

2. **What's the loss denominator?** If the report says loss was measured "across N samples," N tells you everything. Ten samples can detect an outage. Detecting the 0.5-1% loss that degrades real calls takes thousands of packets.

3. **What does "jitter" mean here?** Ask whether the number is the variance of timed requests or the interarrival variation of paced media packets. The two can differ by an order of magnitude on the same network, and [the estimator behind the number changes what it can see](/blog/rtcp-how-phones-measure-quality).

4. **Is the score a standard or an invention?** A MOS computed with the ITU-T G.107 E-model is a published, criticizable method; you can [explore exactly how each impairment moves it](/tools/mos-explorer). A proprietary "readiness score" is a number whose meaning lives in marketing copy. Invented scores usually exist because the underlying data couldn't support a standard one.

5. **What do you pay, and when?** A test that gates the run behind an email address is telling you what it's for. That's a lead-capture form with a diagnostic attached. There are legitimate reasons a business collects emails, but "before any measurement begins" is a choice, and it's not a measurement choice.

## Where our test stands, including its limits

Our [free test](/tools/voip-test) is in the fourth category: it establishes real media sessions and streams codec-encoded audio with real packet sizing and pacing, with up to four genuinely concurrent simulated calls, so multi-call runs measure actual contention rather than extrapolating from one. Every packet is timed, loss is counted against the full stream, and the result is a [MOS](/blog/understanding-mos-scores) computed with the ITU-T G.107 E-model alongside the packet-level metrics it derives from. No email address, no account, and the [report](/tools/voip-test) is a link you can share.

The limits are worth stating just as plainly, because the argument of this post cuts both ways. A browser test measures the path between your device and our servers: a real path carrying real voice-shaped traffic, but not literally your provider's path, and results reflect the device and network you run it from. It is not a speed test and won't tell you your line rate. And nothing running in a browser can conclusively detect SIP ALG, ours included; that verdict belongs to a handset. A test that's honest about the boundary between what it measured and what it inferred is the whole point; it's the standard we're holding the category to, so it's the standard we hold ourselves to.

The next time a page offers to test your VoIP in sixty seconds, take it up on the offer, with the network tab open. What flows during those sixty seconds is what got tested. Make sure it looks like a phone call. And remember that even an honest sixty seconds [cannot qualify a network](/blog/short-tests-cant-qualify-a-network) on its own; duration is a dimension of its own.

---

## A 60-Second Test Can't Qualify a Network

URL: https://voiptest.com/blog/short-tests-cant-qualify-a-network
Published: 2026-08-15
Category: Fundamentals
Tags: voip-test, network-qualification, monitoring, intermittent-problems, testing-methodology, msp

Somewhere right now, a network is being "qualified" for a phone system with a sixty-second test. The result came back clean, the box got checked, the order got signed. And three weeks after cutover, calls are choppy every afternoon and everyone is staring at a report that says the network was fine.

Both things are true. The network *was* fine, for the sixty seconds someone happened to measure it. That's what a clean short test actually proves, and the distance between that and "this network is ready" is where most post-install misery lives.

## The asymmetry every tester should understand

Short tests aren't worthless. They're asymmetric.

A short test that **finds** a problem has proven something real. The loss was measured, the jitter was recorded, the evidence is timestamped in the report. If sixty seconds of real voice-shaped traffic comes back with 2% loss, you don't need a longer test; you need to fix the network.

A short test that **comes back clean** has proven something much smaller: the network behaved during that one window. That's a data point, not a verdict. It cannot speak for the 2:47 PM congestion peak, the Tuesday invoice run, or the backup job that saturates the uplink at 1 AM while the night shift is on the phones.

This is the same asymmetry as any spot check: catching a failure is conclusive, observing an absence is one sample. The mistake isn't running short tests. The mistake is treating a clean one as a qualification.

## What only shows up over time

The problems that survive a pre-install check and ambush a deployment afterward are almost never constant. They have schedules.

**Daily congestion cycles.** Shared infrastructure has rush hours. [Afternoon call quality problems](/blog/afternoon-call-quality) are a well-worn pattern precisely because usage peaks are predictable, and precisely because nobody runs their test at 2:45 PM on a busy Wednesday. On [cable internet](/blog/cable-internet), the whole neighborhood's habits are part of your network's behavior, and a morning test knows nothing about them.

**Load the test didn't generate.** A network that's clean with one test call can degrade when the office itself is busy: everyone on the phones, video meetings running, a large file sync in the background. Testing with [several genuinely concurrent calls](/tools/voip-test) closes part of this gap (contention between simultaneous streams is measured, not extrapolated), but the office's full working load only exists during the working day. You have to be measuring while it happens.

**Scheduled jobs.** Backups, offsite replication, cloud sync, patch downloads. These are polite enough to run at night, which is exactly when nobody tests, and exactly when a call center's overnight shift discovers them.

**Event-driven trouble.** DHCP lease renewals, failover flaps, a wireless access point that drops its clients every few hours, equipment that misbehaves once a day. These aren't patterns so much as landmines with timers, and the only test that catches one is the test that was running when it went off.

None of this is exotic. It's the ordinary texture of real networks, and it's all invisible to a snapshot.

## Why the 60-second free pass persists

If short tests can't qualify networks, why is the sixty-second qualification everywhere? Because it serves everyone in the transaction except the person who'll be on the phones. (It compounds, too: [most free tests aren't measuring voice in the first place](/blog/most-voip-tests-dont-test-voip), so the typical "network qualified" checkbox rests on sixty seconds of the wrong measurement.)

For a vendor, a fast clean test is a fast signed order. For a provider in a quality dispute, a clean snapshot from their own tool is a free pass: *we tested it, the network's fine.* One data point, gathered at a moment of their choosing, waved at a problem that lives at a different hour of the day. This is how disputes stall: each side holding a snapshot from a different moment, both of them "right."

Time-correlated data ends that conversation differently. "Loss spikes to 3% every weekday between 2 and 4 PM, here are the timestamps" isn't an opinion to argue with; it names a window, implies a cause, and tells whoever owns that window exactly where to look. A pattern with timestamps is actionable. A snapshot is deniable. That's the entire difference between evidence that settles a dispute and evidence that prolongs one.

## What qualification actually takes

To qualify a network (to say with a straight face that it's ready to carry a business's calls) you need to observe a full business cycle. The morning ramp, the afternoon peak, the after-hours job window, and enough days to tell a bad Tuesday from a bad network. In practice that's 24 to 48 hours of continuous measurement, running the same real voice-shaped traffic a snapshot test uses, but running it *through* everything the network actually does in a day.

That kind of run produces a different deliverable. Not a score, but a record: quality over time, aligned against the clock, with every excursion timestamped. For an MSP qualifying a site before an install, it's the difference between "it tested fine when we visited" and "we watched it for two days; here's the window that needs fixing before cutover." For anyone in a dispute, it's the difference between contradicting the provider's snapshot with your own, and handing them a pattern they can't test their way around.

## Being honest about the tool you're reading this on

Our [free test](/tools/voip-test) is a snapshot, and we built it that way on purpose: it answers "is something wrong right now, and what?" with per-packet evidence, in about a minute, with no install and no account. When it finds a problem, that finding is solid; the asymmetry works in your favor. And you can stretch it meaningfully: run up to four concurrent calls for up to three minutes, run it *at the hours that hurt*, and run it repeatedly. Every run is a timestamped, shareable report, and a sequence of reports across a day is a crude, honest time series that has settled real disputes.

What a browser tab can't do is stay resident on the network for two days. That's what our testing appliance is for (currently in alpha, expected to launch in Q4 2026). It's designed to be exactly as easy as the browser test: plug it into the network you're qualifying, walk away, and let it run the same real-media measurement continuously: a 24-48 hour qualification pass before an install, or permanent monitoring with alerting after one. The measurement engine, the scoring, and the shareable evidence are the same ones the free test uses today; the appliance's job is to keep them running through every hour a snapshot would have missed.

Until then, hold every test, ours included, to the standard this post argues for. Ask what a clean result actually proved, and when. Sixty seconds of green is a fine start to a qualification. It is never the end of one.

---

## The Cost of Bad Call Quality: What Latency Does to a Conversation

URL: https://voiptest.com/blog/cost-of-poor-call-quality
Published: 2026-08-14
Category: Guides
Tags: call-quality, latency, jitter-buffer, customer-experience, turn-taking, mos

When your phone system goes down, everyone knows within minutes. We covered what that costs, and how to put a defensible dollar figure on it, in [The True Cost of a Phone Outage](/blog/true-cost-of-voip-outage). But an outage is the easy case. It's loud, it's binary, and it ends.

Degraded call quality is the opposite: a slow bleed that never trips an alert, never generates a ticket, and never ends on its own. The calls connect. The audio is clear. And yet every conversation is slightly worse than it should be: people interrupting each other, apologizing, repeating themselves, wrapping up early. Nobody reports it, because there's nothing obviously broken to report. It just quietly costs you, call after call, month after month.

This post is about what latency actually does to a conversation, where the delay hides so that your ping tests never see it, and what the slow bleed adds up to in business terms.

## A phone conversation is a precisely timed activity

Conversation looks casual, but the timing underneath it is remarkably tight. A large cross-linguistic study published in PNAS in 2009 (Stivers and colleagues, covering ten languages from Danish to Yélî Dnye) found that the gap between one person finishing a turn and the other person starting is typically around 200 milliseconds, with the most common response offset sitting near zero. That's faster than most people can consciously react, which means listeners aren't waiting for you to finish and then deciding to speak. They're predicting your endpoint while you're still talking and launching their response to land right on it.

That prediction machinery is calibrated for face-to-face timing: essentially zero transmission delay. Phone networks add delay, and here's the part that matters: **the timing channel breaks long before the audio channel does.** A call with 300 milliseconds of one-way delay sounds perfect. Every word is intelligible. But every turn transition is now off by more than the entire natural gap, in each direction.

The ITU's guidance reflects this. ITU-T Recommendation G.114, the standard for one-way transmission time, says that if mouth-to-ear delay stays below about 150 milliseconds, most applications experience "essentially transparent interactivity." From 150 to 400 milliseconds, calls are still considered acceptable for planning purposes, but with increasing degradation the higher you go, and highly interactive conversations suffer first. Above 400 milliseconds, G.114 treats the delay as unacceptable for general network planning; testing behind the recommendation found that even with echo fully controlled, a meaningful share of speakers had difficulty at that level.

Notice what those numbers describe: not audio fidelity, but *interactivity*. The standard is effectively measuring how badly the delay breaks turn-taking.

## The talk-over spiral

Here's the mechanism, step by step, on a call with meaningful delay in both directions.

You finish your sentence. The other person hears your last word a few hundred milliseconds later, starts responding on their normal ~200 ms reflex, and their first word takes another few hundred milliseconds to reach you. From your side, the silence after your sentence has now stretched to two or three times what your brain expects. Silence that long means one thing in a normal conversation: it's still your turn, or they didn't hear you. So you start talking again, right as their delayed response finally arrives.

Now you're both speaking. Both of you hear the collision (late), both stop, both say some version of "sorry, go ahead." Then you each wait an extra-long beat to make sure the other is really done (which reads as *another* awkward silence), and someone jumps in again. After two or three collisions, both parties give up on natural turn-taking entirely and fall back to deliberate half-duplex: long pauses, explicit hand-offs, the conversational equivalent of radio operators saying "over." It works, but it's slow, tiring, and cold.

Echo makes the spiral worse. Echo cancellers have the hardest job during *double-talk*, the moments when both parties speak at once, which is exactly what excess delay produces more of. So the calls with the worst talk-over also tend to develop clipped syllables or echo artifacts at precisely the collision moments, compounding the confusion. (See [Echo on VoIP Calls](/blog/echo-on-voip-calls) for why delay and echo are so tightly linked: the same echo becomes dramatically more annoying as delay grows.)

If you want the troubleshooting playbook for this symptom (finding which component adds the delay and fixing it), that's covered in [Audio Delay and Talking Over Each Other](/blog/audio-delay-talking-over). This post is about the other half: recognizing that the symptom exists at all, and what it's costing you while it goes undiagnosed.

## Where the delay hides

The reason this problem survives undetected in otherwise well-run networks is that the number everyone checks (network round-trip time) is only one line item in the real budget. What matters to the conversation is *mouth-to-ear* delay: every millisecond between a sound leaving your mouth and arriving at the other person's ear. That's a sum, and most of the terms don't show up in a ping.

Think of it as a delay budget, itemized per hop:

- **Codec and packetization.** The sending side has to collect a packet's worth of audio (usually 20 ms) before it can send anything, plus encoding time and any lookahead the codec needs. Call it a few tens of milliseconds before the first bit touches the network. Details in [Latency, Jitter, and Packet Loss](/blog/latency-jitter-packet-loss-details).
- **Network transit.** The part your ping test actually measures: one-way, roughly half your RTT to the far end.
- **The jitter buffer.** The big hidden one. The receiving side deliberately holds packets in a buffer so that variation in arrival times ([jitter](/blog/what-is-jitter-and-why-it-matters)) doesn't cause gaps in playback. That smoothness is purchased with delay, one-for-one. A well-tuned adaptive buffer might hold a few tens of milliseconds. But a fixed buffer set defensively large, or an adaptive buffer that grew during a jitter spike and was slow to shrink back, can be holding 100 milliseconds or more of your budget, on *each* end of the call. None of it appears in any ping test, because it's not network delay at all. It's your own equipment, waiting on purpose.
- **Headsets and handsets.** A Bluetooth headset adds its own radio link and codec processing: commonly several tens of milliseconds for call audio, and well over 100 ms for some codec configurations. DECT cordless handsets add their own smaller processing delay. If both parties wear Bluetooth headsets, you've added a meaningful chunk of budget that no network tool can see.
- **Transcoding and middleboxes.** Each codec conversion at a PBX or SBC adds more.

Add it up honestly and the arithmetic gets uncomfortable fast. A 60 ms one-way network path (perfectly respectable) plus packetization, a conservatively-sized jitter buffer on each end, and a Bluetooth headset on each end can land you past 250 ms mouth-to-ear. Everyone involved checks the ping, sees 120 ms RTT, and declares the network fine. The network *is* fine. The conversation isn't.

This is why voice is such an unforgiving workload: it's the only common application where a quarter-second of buffering, invisible and harmless anywhere else, directly degrades the product. We dig into that theme in [Why Voice Is Hard](/blog/why-voice-is-hard).

## Why nobody reports it

Choppy audio generates tickets. Words drop out, the caller says "you're breaking up," and someone emails IT with a specific, describable complaint. Latency generates nothing, because there's no *moment of failure* to describe. Nobody files a ticket that says "the conversation felt awkward." They just interrupt each other, apologize, unconsciously shorten the call, form a slightly worse impression of the person and the company on the other end, and call less.

The problem is equally invisible on the monitoring side, for a subtler reason. The MOS number on your dashboard is almost always a *listening quality* score, what ITU-T P.800.1 calls MOS-LQ. It answers: how clear does the received audio sound? Delay doesn't muffle audio, so a high-latency call can score a pristine listening MOS. *Conversational quality* (MOS-CQ, which the ITU E-model captures with an explicit delay impairment term) is a different measurement, and it's the one that collapses when turn-taking breaks. If your tooling only reports listening quality, a call can be conversationally miserable while every metric you collect says it's excellent. (Our guide to [understanding MOS scores](/blog/understanding-mos-scores) covers the distinction, and you can watch delay drag the conversational score down interactively in the [MOS explorer](/tools/mos-explorer).)

So the failure mode is complete: users don't report it, dashboards don't show it, and uptime is 100%. The only way it surfaces is if someone goes looking.

## What the slow bleed costs

The business cost of latency is a customer-experience cost, and it shows up in places nobody attributes to the phone system:

- **Longer handle times.** Every talk-over collision costs a repair loop: stop, apologize, re-establish who's speaking, repeat the lost sentence. On a support call with a dozen turn transitions per minute, those loops add up to real minutes.
- **Lower first-call resolution.** Half-duplex conversations transmit less information per minute, and callers cut awkward calls short. Details get missed; callbacks follow.
- **Damaged rapport on sales calls.** Selling runs on conversational rhythm: matching pace, reading hesitation, well-timed silence. Talk-over torpedoes all of it. A prospect who spends the call fighting for the floor doesn't remember your pitch; they remember the friction.
- **The "cheap" perception.** Callers can't diagnose latency, so they attribute it to the people and the company: distracted, rude, unprofessional, or running discount phone service. Fairly or not, your call quality is part of your brand.
- **Agent fatigue.** People who spend all day pushing conversations uphill end the day more drained, and it compounds: flatter agents produce worse calls, which produce worse outcomes.

### A worked example: the talk-over tax

In the same spirit as the [outage cost exercise](/blog/true-cost-of-voip-outage), here's a deliberately modest model. Every number is an assumption; replace each one with your own. We are not quoting industry statistics, because the honest ones don't exist at this granularity.

**Assumptions:**

- 8 staff spend most of their day on the phone (support and inside sales)
- 25 calls per person per day, 200 calls/day total
- Excess delay adds 20 seconds of pure overhead per call: collision repairs, "sorry, go ahead," repeated sentences, over-long safety pauses (a handful of talk-over incidents per call at a few seconds each; conservative for a genuinely laggy setup)
- Loaded labor cost: $40/hour

**The math:** 200 calls × 20 seconds = 4,000 seconds ≈ 67 minutes of staff time per day, on both ends of a two-party call but we'll count only your side. 67 minutes × $40/hour ≈ **$45/day**, or roughly **$11,000 per year** at 245 working days.

Eleven thousand dollars a year is not a catastrophe; that's rather the point. It's small enough to never force a decision, and large enough to dwarf the cost of fixing it, which is usually a jitter buffer setting, a QoS policy, or an afternoon of measurement. And the measurable time cost is the *floor*. The lost sale that never closed because the rapport never formed, the customer who quietly started emailing instead of calling, the agent who burned out a few months sooner: none of that is in the $11,000, and all of it is real. As with outages, the honest move is to acknowledge the unmeasurable costs exist rather than book them at zero.

## What to do about it

The fix-it playbook lives in the [troubleshooting post](/blog/audio-delay-talking-over); here's the short version, ordered by what this post adds:

1. **Measure mouth-to-ear, not ping.** Your ping test measures one line of the budget. Run a [VoIP quality test](/tools/voip-test) to see latency and jitter under real voice load, then account for the endpoint contributions on top.
2. **Audit your jitter buffers.** Find out whether your phones and PBX use fixed or adaptive buffers and what they're actually holding. A fixed buffer sized for a bad day is charging you that delay on every good day too.
3. **Fix the jitter, not just the buffer.** An adaptive buffer grows because jitter made it grow. Reduce the jitter (QoS, uplink congestion, Wi-Fi) and the buffer can shrink, returning milliseconds to the conversation.
4. **Count your headset hops.** Bluetooth on both ends of a call is a silent budget item. For latency-sensitive roles, wired headsets are the cheapest milliseconds you'll ever buy back.
5. **Test from the actual user setup.** The real path includes the agent's Wi-Fi, their headset, and their VPN, not the ideal-conditions path from the server closet. Test where the conversations actually happen.

The thread running through all of it: conversation is a timed activity, and the timing budget is small. An outage announces itself. Latency never will; you have to go find it, because your callers are already paying for it in three-hundred-millisecond installments.

---

## How to Tell If a VoIP Test Is Actually Testing VoIP

URL: https://voiptest.com/blog/is-your-voip-test-actually-testing-voip
Published: 2026-08-12
Category: Guides
Tags: voip-test, speed-test, network-testing, call-quality, mos-score

Search for a VoIP test and you will get a page of results that mostly measure the same thing. Download speed. Upload speed. A ping figure. Then a verdict: your connection is *excellent for VoIP*.

Run three of them and you may notice the numbers agree suspiciously well, and that all three finish before you have finished reading the page. That agreement is not corroboration. It is a family resemblance.

This is not really an accusation of dishonesty. The tools mostly do what they say: they test your connection speed, and they are frequently right that your connection is fast. The gap is between what they measure and what determines whether your calls sound bad, and that gap is where every unresolved call quality complaint lives. [Why a throughput test cannot measure voice](/blog/why-speed-tests-cant-measure-voip) covers the mechanism in full. This post is the practical companion: how to look at any tool claiming to test VoIP and work out, in about a minute, whether it is doing so.

## Nine tells

None of these require knowing anything about how a tool is built. They are all visible from the outside, while you use it.

### 1. The headline number is in megabits

A single voice call needs roughly 85 kbps: that is G.711 with Ethernet framing, and the figure moves with the codec and the encapsulation, as tell #7 gets into. Not megabits, kilobits. Ten simultaneous calls fit inside 1 Mbps.

If a tool's primary output is "247 Mbps down, 23 Mbps up," it is answering a question that was settled for most businesses a decade ago. The number is not wrong. It is just not about voice. A connection three thousand times wider than a call requires can still deliver calls badly, and the megabit figure will never tell you that.

### 2. Everything else stalls while it runs

Watch what happens to the rest of your connection during the test. If a video call stutters, if a download pauses, if the office notices, the test is saturating your line. That is how throughput measurement works: fill the pipe, see how much fits.

A voice test has no reason to do this. Voice is a trickle. A tool that floods your connection to measure it is measuring capacity, and it is also, briefly, causing the exact congestion that ruins calls. Which brings its own irony: the conditions it creates are conditions it does not report on.

### 3. It is over in seconds

Voice quality problems are rarely constant. They arrive when the office fills up, when a backup kicks off, when a neighbour on the same segment starts streaming. The complaint is almost never "every call is bad"; it is "calls are bad in the afternoon."

A five-second sample cannot characterise a problem like that. It cannot even see it. Any tool that returns a verdict faster than you can read the page has looked at a slice of time far too thin to say anything about how your calls behave.

### 4. It tells you how many calls you can make, and it never placed one

"Your connection supports 230 simultaneous calls."

This is arithmetic: measured bandwidth divided by bandwidth per call. It is also one of the least reliable numbers in the category, because concurrency rarely fails for bandwidth reasons. It fails because a router's session table fills, because a firewall's inspection cost climbs with session count, because something in the path degrades as simultaneous streams multiply. A connection rated for 230 calls by division can start dropping audio at fifteen.

The distinction worth insisting on: did the tool *place* concurrent calls, or did it *divide*? [Concurrent call capacity](/blog/how-many-concurrent-voip-calls) is a measurement, not a calculation, and the two answers can differ by an order of magnitude.

### 5. Packet loss is one number with no pattern

Suppose a tool reports 0.5% loss. That figure is compatible with two very different situations.

Scattered evenly, half a percent is close to inaudible: modern codecs conceal isolated gaps well. Arriving in clumps, the same half a percent takes out whole syllables, and no codec conceals a 100-millisecond hole. Same percentage, entirely different call.

A tool that reports a loss figure without telling you [how the loss arrived](/blog/understanding-voip-packet-loss) has given you a number you cannot act on. Worse, it has given you a number that looks reassuring in the one case where it should not.

### 6. Jitter looks like it came from a ping

Some tools report jitter, which is a good sign until you consider what they measured it on. Variation between a handful of echo probes is not the same measurement as variation across a stream of small packets sent at voice cadence for minutes at a time.

The tell is usually resolution and stability. A jitter figure that barely moves between runs, or that arrives alongside a ping in the same breath, is likely derived from those probes. [Jitter](/blog/what-is-jitter-and-why-it-matters) is about the consistency of a continuous flow, and you cannot characterise a flow you never sent.

### 7. No codec is ever mentioned

The same connection produces different call quality depending on the codec in use. One is intolerant of loss; another conceals it well; another trades bandwidth for resilience. This is not a detail: it can be the difference between complaints and silence on an unchanged network.

A tool that never mentions which codec its verdict applies to is telling you it does not model that, which means its verdict cannot be specific to your deployment.

### 8. The score has no standard behind it

Quality scores out of 100. Five stars. A letter grade. A green tick.

Ask what the number is derived from. Voice quality has a published standard: [the ITU-T G.107 E-model](https://www.itu.int/rec/T-REC-G.107/en), a transmission-planning model that combines the codec's impairment, delay, and effective loss into an R-factor and then an estimated [MOS score](/blog/understanding-mos-scores), which the model's own conversion caps at 4.5 rather than 5. The 1-to-5 range belongs to P.800's listener panels, which is a different thing. (Jitter does not go in raw: it enters through what the jitter buffer does with it, added playout delay and packets discarded for arriving late, so [a tool using G.107 properly has to model that](https://www.rfc-editor.org/rfc/rfc3611.html), not just plug a jitter figure in.) The model is what carriers use for planning, and its virtue is reproducibility: run the same model version with the same inputs and you get the same answer, whoever is running it. That is a real advantage over a proprietary score, but it is conditional: two G.107 results are only comparable when the model version, the codec and equipment impairment values, the treatment of loss, the burst model and the delay inputs all line up. A tool that reports a MOS figure without saying which of those it used has given you a number you cannot reconcile against anyone else's. The model's output is an estimate of what listeners would report, not a listener panel (that is [ITU-T P.800's](https://www.itu.int/rec/T-REC-P.800/en) territory), but a standardised estimate beats a proprietary one every time.

A proprietary score means whatever its author decided. It may be perfectly sensible. It is also unfalsifiable, and it will not survive contact with a provider's support desk, which is usually the moment you need it most.

### 9. It says the same thing at 3am as it does at 3pm

This is the test of the tests, and it costs you nothing.

Run the tool when the office is empty. Run it again at the worst hour of the worst day. If the verdict does not move, one of two things is true: your connection genuinely does not vary, or the tool cannot see variation. The second is far more common, and a tool blind to variation is blind to the single most common shape of a real VoIP problem.

## Why the label sticks

Worth being fair about why this is so widespread, because it is not a conspiracy.

Measuring throughput is easy. Fill the pipe, time it, divide. It works from any browser, finishes fast, needs no infrastructure beyond a big file and a server, and produces a satisfying number.

Measuring voice quality is not easy. It means sending traffic that behaves like voice rather than like a download, watching it for minutes rather than seconds, caring about the arrival time of individual packets rather than their total volume, and interpreting the result against a standard. It is more work, it takes longer, and the output is less immediately gratifying than a big number with an upward arrow.

So the label drifts to the easy thing. "VoIP test" is what people search for; a throughput test is what is cheap to build. Nobody has to be acting in bad faith for the result to be a category full of tools that cannot answer the question being asked of them.

## What to demand instead

Judge any voice test on what it hands you, not on how it describes itself:

- **A score with a published standard behind it.** G.107, stated plainly. If a tool will not tell you what its score is derived from, treat the score as decoration.
- **Loss pattern, not just a loss percentage.** Random, bursty, or periodic. The pattern is the part that points at a cause.
- **A sustained run.** Minutes, not seconds, so intermittent problems have a chance to appear.
- **Real concurrency, if it claims concurrency at all.** Calls placed, not bandwidth divided.
- **Something you can send to someone else.** A shareable, timestamped result is materially harder for a provider to dismiss than "calls sound choppy."
- **Honesty about what it cannot see.** Any browser-based test measures a path. A tool that implies it has inspected your handsets, your PBX, and your carrier's network is overselling, and the overselling tells you something about the rest of its claims.

## Where ours stands

Ours is free, needs no account, asks for no microphone, and runs in a browser tab.

It places between one and four **genuinely concurrent calls**: separate calls running at the same time, competing for your connection the way real calls do, not one call's numbers multiplied. You choose 60 seconds, 2 minutes, or 3 minutes, so you can watch a connection for long enough to catch it misbehaving. It scores with the **ITU-T G.107 E-model**, the same planning standard a carrier would use, and shows the working rather than just the verdict. That score is a standardised estimate of the path's quality, not a transcript of what a particular caller heard (no computed MOS is), but it is the kind of estimate a provider's engineers use themselves, which is why it survives being forwarded to them. It classifies your loss as random, bursty, or periodic. On multi-call runs it breaks out each call individually, so you can see whether your connection degrades under load or holds steady. Every result gets a shareable link you can drop into a support ticket, and a [guide to reading the numbers](/tools/voip-test/results-guide) so the report is useful to someone who does not do this for a living.

How it does that is not something we are going to write up, and you should be mildly suspicious of any tool in this category that does: method is the only durable difference between a real voice test and a throughput test with a voice label on it.

What we will do is be straight about the limits. Our test measures the path between your browser and our servers. That covers your local network, your equipment, your ISP, and the internet leg, which is where the large majority of call quality problems actually live. It does not cover your handsets, your PBX configuration, your SIP trunk, or the leg between your provider and the person you called. A clean result narrows the search considerably. It does not end it, and we would rather say so than let you find out later.

## The one-minute version

Open whatever tool you are evaluating and ask three questions.

Is the biggest number on the screen measured in megabits? Did it finish before you could read the page? And if you run it again tonight, will it say anything different?

Three yeses means you have a speed test. It may be a very good speed test. It is not going to tell you why your calls sound bad.

---

*For the underlying reasons a throughput measurement cannot capture voice quality, see [Why a Speed Test Can't Tell You If VoIP Will Work](/blog/why-speed-tests-cant-measure-voip). For using test results methodically rather than one-off, see the [VoIP quality testing methodology guide](/blog/voip-quality-testing-guide).*

---

## The True Cost of a Phone Outage (and How to Calculate Yours)

URL: https://voiptest.com/blog/true-cost-of-voip-outage
Published: 2026-08-11
Category: Guides
Tags: downtime, business-continuity, sla, redundancy, failover, outage-cost

Every business owner knows a phone outage is bad. Very few can tell you what one actually costs them, in dollars, per hour. That gap matters, because without a number you can't make rational decisions about how much to spend preventing outages. You end up either underinsured (no failover at all, because redundancy "seems expensive") or overinsured (paying for geo-redundant trunks when call forwarding to a mobile would cover you).

This post walks through the three categories of outage cost (visible, invisible, and asymmetric) and then builds a worked example for a 20-person business so you can plug in your own numbers. We'll deliberately avoid quoting "industry average cost of downtime" figures. Those numbers are dominated by enterprise data-center outages and tell you nothing about your business. Your own math, with your own assumptions written down, is worth more than any survey.

## The visible costs

These are the costs you can see happening in real time while the phones are down. They're the easiest to estimate, and they're usually the largest line items.

### Missed inbound sales calls

If inbound calls generate revenue for you, this is the big one. The math is straightforward:

**Lost sales per hour = inbound sales calls per hour × close rate × average deal value**

You already have all three inputs, or can get them quickly:

- **Inbound sales calls per hour.** Pull your call logs or ask whoever answers the phone. Count only calls that could plausibly turn into revenue (new inquiries, quote requests, orders), not vendor calls or existing-ticket follow-ups.
- **Close rate.** What fraction of those inquiries eventually become paying customers? Your sales team or your CRM knows this. If you don't track it, estimate conservatively and write the assumption down.
- **Average deal value.** Revenue per closed deal, or lifetime value if a new customer typically buys repeatedly. Use whichever number you'd actually defend to your accountant.

One honest caveat: not every missed call is a lost sale, because some callers will try again later. But during an outage your phones don't ring busy-with-a-queue; they're dead. A caller who hears fast busy or endless ringing has no idea you're having a technical problem. Which brings us to the invisible costs in a moment.

### Abandoned support calls and churn risk

If you provide support by phone, an outage means existing customers who need help right now can't reach you. Unlike a missed sales call, the cost here isn't a single lost transaction; it's an increment of churn risk on an existing revenue stream.

A customer who calls with an urgent problem and gets dead air doesn't file that under "stuff happens." They file it under "this vendor is unreliable," and it goes on the mental ledger they'll consult at renewal time. You can't compute this precisely, but you can bound it: estimate how many support calls you'd miss during the outage, estimate what fraction of those customers are already borderline, and multiply by the annual value of a customer. Even a small probability times a large customer value is a real number.

### Idle staff

While the phones are down, you're still paying everyone whose job depends on them. A salesperson who works the phones, a dispatcher, a receptionist, a support agent: their productivity doesn't drop to zero (they can catch up on email), but it drops substantially.

**Idle staff cost per hour = phone-dependent employees × loaded hourly cost × productivity loss fraction**

Loaded cost means salary plus benefits and overhead; a common shortcut is wages × 1.25 to 1.4. The productivity loss fraction is a judgment call; 50% is a reasonable default for roles where the phone is the primary tool. Write down whatever you use.

## The invisible costs

These costs don't show up during the outage. They show up weeks and months later, as revenue that quietly never materializes, which is exactly why they get left out of the calculation.

**Callers who never call back.** Some fraction of the people who got fast busy during your outage will simply move on. A prospect comparing three vendors calls the next one on the list. A new customer referral, told "just give them a call," gets no answer and lets it drop. You'll never see these losses in any report because there's no record the call was ever attempted from your side. Your provider can sometimes give you counts of failed inbound attempts during an outage; it's worth asking, because that number is usually higher than people expect.

**Reputation damage.** The prospect who couldn't reach you tells the person who referred them. A customer mentions in a review that "they're impossible to get on the phone." Each individual incident is small; the compounding effect is not. Reputation is expensive to build and cheap to lose, and phone reachability is one of the most basic trust signals a business has.

**Callers who assume you went out of business.** This one sounds dramatic but it's real, especially for outages that span a day or more. A disconnected-sounding phone line is the classic signal of a business that has folded. An occasional customer who calls twice, a week apart, and gets dead air both times will reasonably conclude you're gone, and unlike the impatient prospect, they won't check your website to confirm.

You can't put precise numbers on these. The honest approach is to add an uncertainty allowance on top of your visible costs (25 to 50% is defensible) rather than pretending the invisible costs are zero, which is the one estimate you can be certain is wrong.

## The asymmetric costs

The first two categories scale roughly linearly with outage duration. This third category doesn't. These are low-probability, high-severity events where a single incident during a single outage can dwarf everything else on the list.

**A missed emergency call.** If your business fields calls where the stakes are safety or health (a medical practice, a property manager with a gas leak on the line, an HVAC company in a heat wave, a security monitoring firm), one missed call can carry consequences measured in liability and harm, not in average deal values. No hourly cost model captures this. If it applies to you, it's a reason to be at a higher failover tier regardless of what the spreadsheet says.

**SLA penalties you owe your own customers.** This one is easy to overlook and especially relevant for MSPs and anyone reselling voice services. If you've signed uptime commitments with your customers, your provider's outage becomes your SLA violation. You owe credits, or worse, you've given an anchor customer contractual grounds to leave. Note the asymmetry: the credits you owe downstream are governed by your contracts, while the credits you receive upstream are governed by your provider's. Those two numbers were never designed to match, and they don't.

**Compliance exposure if 911 is unreachable.** In the US, Kari's Law and RAY BAUM'S Act impose requirements around 911 access and dispatchable location for multi-line phone systems. If your phone system is down and someone in your building can't reach 911, you have a problem that is categorically different from lost revenue. This is another factor that should push safety-relevant environments toward faster, more automatic failover: the kind measured in seconds, not in someone noticing and forwarding calls manually.

## Why your provider's SLA credit won't cover any of this

It's tempting to think of your provider's SLA as insurance against outage costs. It isn't, and it was never designed to be.

As we covered in detail in [SLAs: The Contract Language That Actually Matters](/blog/sla-contract-language), service credits are calculated as a percentage of your monthly bill per increment of downtime, and capped, typically at 30 to 100% of one month's charges. The credit is indexed to what you pay the provider, not to what the outage costs you. If your phone service costs $600 a month and an outage costs you $1,000 an hour, the best possible outcome under most SLAs (the full cap) recovers well under one hour of your actual losses. And you usually have to notice the violation, document it, and file a claim within a deadline to get even that.

SLA credits exist to give the provider a financial incentive to hit their targets. They are not a remedy for your business impact. The remedy for business impact is redundancy, and redundancy is something you have to budget for yourself, which is exactly why you need the number we're about to calculate.

## A worked example: 20-person business

Let's put the pieces together for a hypothetical 20-person company: a distributor, an agency, a service firm, take your pick. Every assumption is labeled; replace each one with your own figures.

**Assumptions:**

- 40 inbound calls per 8-hour business day, of which 10 are potential sales inquiries
- Close rate on phone inquiries: 20%
- Average deal value: $2,500
- 12 of the 20 employees are phone-dependent, at an average loaded cost of $45/hour, losing 50% productivity during an outage
- 8 support/service calls per day from existing customers, average customer worth $6,000/year, and we'll say a badly-timed missed call adds a 2% chance that customer eventually churns

**Missed sales:** 10 sales calls ÷ 8 hours = 1.25 sales calls per hour. 1.25 × 20% × $2,500 = **$625 per hour**.

**Idle staff:** 12 × $45 × 50% = **$270 per hour**.

**Churn risk:** 8 support calls ÷ 8 hours = 1 per hour. 1 × 2% × $6,000 = **$120 per hour** in expected value.

**Visible subtotal: about $1,015 per hour.** Add a 30% allowance for the invisible costs (the callers who never retry, the reputation dings) and you land at roughly **$1,300 per hour of downtime**.

So a four-hour outage costs this business somewhere around $5,300. A full-day outage costs over $10,000. Meanwhile, if their phone service runs $500/month, a typical SLA credit for that four-hour outage might be $100, capped well below one month's bill. The gap between those two numbers ($5,300 of loss against $100 of credit) is the entire argument for doing this exercise.

Your numbers will differ, possibly by a lot. A business where the phone rarely rings might land at $150/hour; a busy inbound sales operation might land at $5,000. That's precisely the point: the spend that's rational for one is irrational for the other, and only the calculation tells you which one you are.

## Using the number: right-sizing your failover spend

Here's where the number earns its keep. Redundancy budgeting is a business decision, not a technical one, and your outage cost per hour is the input that turns "how much redundancy should we buy?" from a matter of taste into arithmetic.

The comparison works like this:

**Expected annual outage cost = cost per hour × expected hours of downtime per year**

For the downtime estimate, look at your own history: how many outages did you have in the last two or three years, and how long did they last? For this worked scenario we'll assume a single ISP connection with no backup sees 8 to 20 hours of downtime per year between ISP outages, equipment failures, and upstream problems (an illustrative planning assumption, not a measured industry figure). Use your actual track record, not our guess. (For what an outage actually does to your phones minute by minute, see [What Happens to Your Phones When the Internet Goes Down](/blog/what-happens-to-phones-when-internet-goes-down).)

For our example business at $1,300/hour, even the low end of that assumed range (8 hours of annual downtime) is roughly $10,000 of expected annual loss. Against that:

- **Free call forwarding to mobile** (Tier 1 in our [failover architectures guide](/blog/voip-failover-architectures)) costs nothing and is worth configuring before you finish reading this. How much of the inbound loss it actually recovers depends on your situation: how many numbers you can forward, how many mobiles are available to receive, and whether the people answering them can do the work that the call was about. For a small team with a handful of numbers it can recover a lot. For a queue that normally lands on twenty agents with a CRM in front of them, it recovers the call but not the transaction.
- **A cellular backup connection** at $50-100/month (call it $1,000/year with hardware) substantially reduces the remaining exposure, provided the cellular path actually fails independently of your primary: check for shared power, shared equipment, and cellular coverage at your site before counting on it. Against $10,000 of expected loss, that's still not a close call.
- **Dual WAN with automatic failover** at a few thousand per year still pays for itself comfortably for this business, but might not for the $150/hour business, which is exactly the kind of distinction the number lets you make.
- **Geo-redundant trunking** at $12,000+/year is hard to justify at $1,300/hour on financial grounds alone. It becomes justifiable when the asymmetric costs apply (emergency calls, downstream SLAs, compliance) or when your hourly number is several times higher.

Two closing disciplines make the whole exercise durable. First, revisit the calculation annually; call volumes, deal sizes, and headcount all drift, and the failover tier that was right two years ago may be wrong now. Second, whatever failover you deploy, verify it actually works, including running a [VoIP quality test](/tools/voip-test) over the backup path so you know it can carry your call volume before the day you need it.

The businesses that get this right aren't the ones that spend the most on redundancy. They're the ones that know their number.

---

## How Many Concurrent VoIP Calls Can Your Internet Connection Handle?

URL: https://voiptest.com/blog/how-many-concurrent-voip-calls
Published: 2026-08-10
Category: Guides
Tags: concurrent-calls, bandwidth, sip-trunking, capacity-planning, codecs, voip-quality

Search for "how many concurrent VoIP calls can my connection handle" and you will find the same answer repeated across a hundred vendor blogs: divide your bandwidth by ~100 Kbps per call, and behold: your 100 Mbps connection supports 1,000 simultaneous calls. The arithmetic is correct. The answer is wrong, usually by an order of magnitude, and businesses discover this the hard way at 10 a.m. on their busiest Monday.

This post covers both halves of the real answer: the per-codec math you need for planning (which is genuinely useful), and the reasons that math falls apart on real networks (which is where quality actually dies). Then a realistic way to derate the estimates, and how to replace estimating with measuring.

## How much bandwidth does one VoIP call use?

A voice call is a stream of small packets sent at a fixed rate: with the standard 20 ms packetization, exactly 50 packets per second in each direction. Each packet carries a slice of encoded audio wrapped in RTP, UDP, and IP headers, plus link-layer framing. The wrapping is not trivial: the 40 bytes of IP/UDP/RTP headers are pure overhead on every one of those 50 packets per second, and for compressed codecs the headers can outweigh the audio itself.

Here is what the common codecs actually consume per direction, overhead included:

| Codec | Audio bitrate | Bandwidth on the wire (per direction) | Notes |
|---|---|---|---|
| G.711 | 64 Kbps | ~87 Kbps | The default on most SIP trunks; uncompressed telephone-quality audio |
| G.722 | 64 Kbps | ~87 Kbps | "HD voice": wider frequency range at the same bitrate as G.711 |
| Opus | 12–32 Kbps typical for voice | ~30–50 Kbps | Used by browser calling, Teams, and modern softphones; adapts its bitrate |
| G.729 | 8 Kbps | ~32 Kbps | Licensed compression codec; noticeably lower fidelity, historically used on thin WAN links |

Two things to internalize from this table. First, the codec matters enormously: a G.729 call uses roughly a third of the bandwidth of a G.711 call. Second, voice is symmetric. Both parties talk, so every call consumes its full bandwidth figure upstream and downstream at the same time. There is no "mostly download" discount like web browsing gets.

## How many calls per Mbps: the naive arithmetic

Divide and conquer. At ~87 Kbps per direction, G.711 gives you about 11 concurrent calls per Mbps. G.729 and low-bitrate Opus give you roughly 30 per Mbps. Scale it up:

- **10 Mbps**: ~115 G.711 calls, ~310 G.729 calls
- **50 Mbps**: ~570 G.711 calls, ~1,560 G.729 calls
- **100 Mbps**: ~1,145 G.711 calls, ~3,125 G.729 calls

These numbers assume the link is symmetric, empty, perfectly behaved, and carrying nothing else. Every one of those assumptions is false on a real network, which is why a 20-person office on a "100 Mbps" cable connection can experience choppy audio with six calls up. If you want to run this math for your own codec mix and call counts, our [bandwidth calculator](/tools/bandwidth-calculator) handles the packetization and overhead details, but treat its output as a floor requirement, not a capacity promise.

The gap between the spreadsheet and the Monday-morning reality is the rest of this post.

## Why the naive math fails in practice

### Upload asymmetry: your connection is smaller than you think

Voice needs the same bandwidth in both directions, but most consumer and small-business connections are dramatically asymmetric. Cable plans sold as "500 Mbps" commonly ship with 20 or 35 Mbps upload. DSL is worse. Even "dedicated" fiber-like products from cable operators often keep the asymmetry.

Since a call dies the moment either direction degrades, your VoIP capacity is set by the *smaller* number. That 500/20 plan is a 20 Mbps connection for voice purposes: ~230 G.711 calls naively, and far fewer in practice. This single fact (upload is the ceiling) explains a majority of "we have plenty of bandwidth" complaints. It also explains why the failure mode is usually one-sided: the far end hears you break up while you hear them fine, because your saturated upload path is mangling outbound audio while the roomy download path delivers inbound audio untouched.

### Quality collapses on timing, not throughput

Here is the deeper problem: voice does not fail when bandwidth runs out. It fails when *timing* runs out, and timing degrades much earlier.

VoIP packets must arrive at a steady 20 ms cadence. The receiving side's jitter buffer can absorb some variation, but every millisecond of buffering is added latency, and packets that arrive too late get discarded exactly as if they had been lost. What matters to call quality is [latency, jitter, and packet loss](/blog/latency-jitter-packet-loss-details), and all three climb steeply as a link approaches saturation, well before utilization hits 100%.

The mechanism is queuing. As traffic approaches link capacity, packets start waiting in router buffers. Delay through a queue is nonlinear: nearly zero at 50% utilization, noticeable at 70%, and exploding past 85–90%. Your voice packets are now standing in line behind file syncs and video frames, arriving in erratic clumps rather than a smooth stream. The bandwidth accountant says you have 15% headroom; the jitter buffer says the call is unusable.

### Bufferbloat: the saturated-pipe disaster

Modern routers and modems ship with buffers sized for throughput benchmarks, not for latency. When the link saturates (one large upload, one cloud backup, one employee seeding a video call recording) those oversized buffers fill completely and *stay* full. Every packet, voice included, now waits behind the entire buffer. On consumer gear this routinely adds 200 ms to over a second of delay in the saturated direction.

A one-way delay of 400 ms doesn't make a call sound bad; it makes conversation impossible. People talk over each other, pause, apologize, and talk over each other again. And bufferbloat is invisible to a speed test, which happily reports full throughput while latency under load has gone through the roof. This is a core reason [speed tests can't measure VoIP readiness](/blog/why-speed-tests-cant-measure-voip): they measure the one dimension of the connection that voice barely uses, and ignore the dimensions voice lives or dies on.

### Voice never gets the link to itself

The naive math implicitly assumes the pipe carries nothing but calls. Your actual link carries email, SaaS apps, video meetings, OS updates, cloud backups, security camera uploads, and whatever a guest device decides to sync. Video conferencing alone is brutal company for VoIP: a single group video call can consume 2–4 Mbps of the same scarce upload bandwidth, with its own bursty pattern.

Realistic planning starts by subtracting normal peak data usage from the link, then fitting calls into what remains. For most offices, voice gets perhaps half the nominal upload capacity on a good day, and the bad days are precisely the busy days when call volume also peaks.

### QoS decides who suffers

Whether contention turns into call degradation depends on queue management at your edge. A router with working QoS (voice packets classified and prioritized, ideally with modern queue disciplines that keep buffers shallow) can hold jitter down even at high utilization, because voice packets jump the queue. A router with no QoS treats a voice packet and a backup packet identically, and voice loses every time because it cannot wait.

The catch: QoS only works where you control the queue, which means your own router and LAN. Once packets leave your edge, prioritization markings are typically ignored. QoS therefore fixes the most common failure point (your own congested upload queue) but it cannot fix an undersized link or a poor ISP path. It changes how gracefully you degrade, not the ceiling itself.

## SIP trunk capacity: channels are not bandwidth

A note for anyone sizing trunks rather than just the pipe: SIP trunk capacity and bandwidth capacity are two separate limits, and you need both.

A SIP trunk is sold in concurrent call paths (channels or sessions). Twenty channels means call 21 gets a busy signal regardless of how much bandwidth you have. Providers size trunks with concentration ratios (assumptions about how many users are actually on calls at once) and getting that ratio right is its own discipline, covered in our guide to [VoIP overbooking](/blog/voip-overbooking). A call center might need one channel per agent plus queue headroom; a general office often runs comfortably at one channel per 3–5 users.

The failure modes differ usefully. Exceeding trunk capacity fails *cleanly*: a rejected call, a busy signal, an obvious symptom. Exceeding your network's real-world voice capacity fails *dirtily*: every active call degrades simultaneously, nothing is rejected, and the symptom is a slow pile of complaints about "choppy audio sometimes." Size both limits, and if you have to err, err so the clean failure happens first: a trunk cap slightly below what your network can carry beats the reverse.

## What a realistic derating looks like

So how do you turn the naive number into a plannable one? A defensible derating chain looks like this:

1. **Start from measured upload throughput**, not the advertised plan speed. Measure at peak business hours, since cable and shared-media connections vary through the day.
2. **Subtract peak non-voice traffic.** If you can't measure it, assuming half the link is spoken for is rarely far off in an active office.
3. **Cap voice at roughly 30–40% of what remains without QoS, or 60–70% with working QoS** at your edge. This is the queueing-delay reality: past those utilization levels, jitter growth makes calls fragile regardless of what the throughput math says.
4. **Divide by per-call bandwidth** for your codec from the table above.

Run that for a typical "100 Mbps" cable connection with 20 Mbps upload: 20 Mbps measured, minus ~8 Mbps of peak data traffic, times 0.6 with decent QoS, gives ~7 Mbps of dependable voice budget: about **80 G.711 calls**, not 1,100. Without QoS, closer to 40. That is the honest number, and for most small offices it is still plenty; the point is knowing it *before* the trunk order and the go-live, not after.

When can you trust estimates at all? When the inputs are measured rather than advertised, when the link is symmetric or you sized from the upload figure, when QoS is verified working rather than assumed, and when someone owns re-checking the numbers as headcount and usage grow. If you do this professionally across many client networks, our [MSP capacity planning guide](/blog/msp-capacity-planning) covers how to systematize it. If any input is a guess, your capacity number is a guess wearing a spreadsheet.

## Stop estimating: measure the path

Everything above is still math about a network you haven't observed. The step that makes it real is measuring the actual path your calls will take, under realistic conditions, with realistic packets: small, frequent, timing-sensitive UDP streams, not the bulk TCP transfers a speed test uses.

That is exactly what our [free VoIP test](/tools/voip-test) does. It sends real VoIP-style media over your connection, measures the latency, jitter, and packet loss your calls would actually experience, and scores the result as a MOS value. Directly relevant to this post: it will place **up to four simultaneous calls**, each on its own connection with its own media stream, and report how every one of them fared. That is not an extrapolation from a single path; it is four calls contending for your uplink at the same time, which is what four phones do. It takes about a minute, requires no account and no microphone, and gives you a shareable report.

Note what that does and does not tell you. If four calls hold up, you have measured a floor: your connection handled four. It does not follow that it would handle forty; for that, the arithmetic above is still your only guide, and it is only as good as its inputs. The value of measuring is that a floor is a fact, while a projection is a hypothesis.

The workflow, then: use the [bandwidth calculator](/tools/bandwidth-calculator) to establish what your planned call volume demands, run the [test](/tools/voip-test) to establish what your connection actually delivers, and make sure the second number exceeds the first with room to spare. Run the test at your busiest hour, because that is the connection your callers will meet. Capacity planning by division is how VoIP deployments get into trouble; capacity planning by measurement is how they stay out of it.

*For why throughput numbers mislead in the first place, read [why speed tests can't measure VoIP](/blog/why-speed-tests-cant-measure-voip). For the metrics that actually govern call quality, see [latency, jitter, and packet loss explained](/blog/latency-jitter-packet-loss-details).*

---

## SD-WAN and VoIP: What Actually Helps and What's Marketing

URL: https://voiptest.com/blog/voip-sd-wan-reality-check
Published: 2026-08-07
Category: Guides
Tags: sd-wan, call-quality, failover, qos, packet-loss, network-architecture

SD-WAN is one of the most heavily marketed technologies ever pointed at the VoIP problem. The pitch is seductive: run your voice over cheap broadband, let the software sort out the quality, cancel the expensive circuit. Some of that pitch is real engineering. Some of it is a sales deck.

This post separates the two. If you want the broader picture of failover options, from simple call forwarding up through geo-redundant SIP trunks, read [VoIP Failover in Practice](/blog/voip-failover-architectures) first. This one is narrower: what SD-WAN specifically does for voice, what it physically cannot do, and how to evaluate a deployment before you sign anything.

## What SD-WAN actually is

Strip away the branding and SD-WAN is an overlay network. An appliance (or virtual appliance) at your site builds encrypted tunnels across two or more WAN links (fiber, cable, LTE, whatever you have) and continuously measures each tunnel's loss, latency, and jitter. A policy engine classifies traffic by application and decides, per flow or per packet, which tunnel each packet should ride.

That's it. Everything else (the dashboards, the "intelligent edge," the cloud orchestration) is management tooling wrapped around those two capabilities: multiple paths, and measured, application-aware selection between them.

Two things follow immediately from that definition, and they frame everything else in this post:

1. **SD-WAN needs multiple genuinely independent paths to do its best work.** With one link, most of its machinery is idle. With two links that fail together, it's theater.
2. **SD-WAN operates between your edge and wherever the tunnels terminate.** It has no authority over your LAN on one side or the far-end network and PSTN handoff on the other. Problems in those segments pass straight through.

## The mechanisms that genuinely help voice

The real value for VoIP comes from a handful of specific mechanisms. When a vendor demo impresses you, one of these is doing the work.

### Quality-based path selection

Traditional dual-WAN failover asks one question: is the primary link up? SD-WAN asks a better one: which link is currently best for voice? The appliance sends probe traffic (or measures live traffic) across every tunnel and tracks loss, latency, and jitter per path. When your fiber circuit starts dropping packets during the neighborhood's evening congestion, voice flows shift to the cable circuit, and shift back when the fiber recovers.

Good platforms do this per flow (a call stays on one path unless that path degrades) and some do it per packet (each packet takes the currently-best path, with reordering handled at the far end). Per-packet steering is more aggressive and can squeeze more out of two mediocre links, but it requires an SD-WAN endpoint at both ends of the tunnel to reassemble the stream.

### Brownout detection

This is arguably the most underrated feature. Most outages that hurt voice are not hard failures: the link stays up, DNS resolves, web pages load, but loss climbs to 3% and jitter triples. A plain failover router sees a healthy interface and does nothing. Your callers hear robotic audio and dropped syllables. (If you need a refresher on why small amounts of loss and jitter are so audible, see [latency, jitter, and packet loss in detail](/blog/latency-jitter-packet-loss-details).)

SD-WAN's continuous per-path measurement means it reacts to degradation, not just death. You define thresholds (1% loss or 30 ms jitter are common operational starting points, but they're operating targets you tune to your codecs and traffic, not universal pass/fail standards) and voice moves off the sick path before users notice. This single behavior is a legitimate step up from conventional dual-WAN.

### Packet duplication across links

For traffic classes you designate as critical, some platforms send every packet down two paths simultaneously and use whichever copy arrives first, discarding the duplicate. Voice is the textbook use case: the streams are small, so duplicating them is cheap, and the payoff is that a lost packet on one link is invisible as long as the other link delivered its copy.

Duplication doubles the WAN bandwidth your calls consume: trivial for voice at tens of kilobits per call, but worth accounting for if one of your links is a metered LTE circuit. Run your numbers through the [bandwidth calculator](/tools/bandwidth-calculator) with the duplication factor included.

The catch: duplication only helps if the two links fail independently. Duplicating packets across two circuits that share a conduit protects you against nothing that matters.

### Forward error correction

FEC sends redundant parity packets alongside the voice stream so the receiving endpoint can reconstruct a limited number of lost packets without retransmission. Unlike duplication it works even with a single decent path, at a lower bandwidth cost. It's effective against scattered random loss and much less effective against burst loss, where several consecutive packets vanish and the parity data can't cover the gap. Vendors tune this differently; ask specifically how their FEC behaves under burst loss, because that's the pattern congested broadband actually produces.

### Jitter buffering and conditioning at the edge

Some appliances smooth the stream inside the tunnel: buffering to even out inter-packet gaps, resequencing out-of-order packets before they reach your PBX or the far end. This overlaps with what your phones' own jitter buffers already do, but doing part of the job at the edge, especially when combined with per-packet steering across paths with different latencies, can present a cleaner stream to endpoints than they'd assemble themselves.

## What SD-WAN cannot fix

Now the physics and the plumbing that no overlay touches.

**Speed-of-light latency.** If your calls traverse 80 ms of geographic distance, they traverse it on every path SD-WAN can choose. Path selection picks the best of your available options; it does not create a shorter one. An overlay can avoid a *congested* route, but it cannot beat the propagation delay of the good route.

**Provider-side and far-end problems.** SD-WAN's tunnels end somewhere: at your other sites, at a cloud gateway, or effectively at the edge of the public internet. Congestion at your VoIP provider, a bad peering link beyond the tunnel terminus, a problem in the PSTN handoff: all invisible to and unfixable by your edge appliance. It will faithfully deliver packets to the far side of its domain, where they proceed to suffer exactly as before.

**A saturated LAN.** If a backup job is flooding your switch or your Wi-Fi is melting down, voice packets are dying before they reach the SD-WAN appliance. No WAN technology helps with a LAN problem. This is where honest [QoS work on your own network](/blog/qos-practical-config) matters, and it's a prerequisite for SD-WAN, not something SD-WAN replaces.

**A physically shared last mile.** This one bites real deployments constantly. You buy "diverse" circuits from two providers, but both ride the same pole line, the same conduit under the same street, or even the same wholesale last-mile infrastructure resold under two brands. One backhoe, one traffic accident, one flooded vault: both links die together, and every clever mechanism above has nothing to work with. We cover how to actually verify path diversity in [Redundancy and Failover: When One Connection Isn't Enough](/blog/redundancy-failover). Ask both providers how their cable physically reaches your building. If you can't get true wired diversity, make the second path wireless: LTE/5G or fixed wireless shares no trench with anything.

## Marketing claims to treat with suspicion

**"MPLS-like quality over broadband."** MPLS circuits come with contractual SLAs on loss, latency, and jitter, enforced by a provider that controls the whole path. Broadband comes with none of that. SD-WAN can combine two broadband circuits into something that *usually behaves* better than either alone; that's real. But it's probabilistic, not contractual. If both circuits degrade at 8 PM because they share upstream congestion, no overlay recreates the SLA. The honest version of the claim is: "two good broadband circuits plus SD-WAN often performs comparably to MPLS at lower cost, and you should verify that for your circuits, in your location, at your busy hour."

**"Eliminates the need for QoS."** This confuses two different jobs. SD-WAN decides *which link* a packet uses. QoS decides *which packet goes first* when a link is momentarily full. Choosing the better of two congested links still leaves you on a congested link, and without per-link prioritization your voice packets queue behind someone's cloud backup. Every competent SD-WAN deployment still configures queuing and shaping on each underlay (usually inside the same appliance), and your LAN switches still need their own policy. The claim is only true in the trivial sense that the SD-WAN box is now where you configure the QoS.

**"Zero packet loss" / "flawless voice."** Read the fine print: these claims describe duplication or FEC working under specific loss patterns on independent paths. Correlated failures, burst loss exceeding FEC's correction budget, or a shared last mile all break the guarantee. The mechanisms are good. The absolutes are marketing.

## How to evaluate SD-WAN for voice, specifically

The evaluation most buyers do (watch a vendor demo, glance at a dashboard, sign) measures nothing. Do this instead:

**1. Measure each underlying circuit independently first.** Before any overlay is involved, run a [VoIP quality test](/tools/voip-test) over each WAN link by itself: loss, jitter, latency, MOS, during your actual busy hours and across several days. This is your baseline, and it answers the question the vendor won't: are these underlays good enough for the overlay to have raw material to work with? A speed test doesn't tell you this: [throughput and call quality are different measurements](/blog/why-speed-tests-cant-measure-voip).

**2. Test through the overlay under the same conditions.** Same tests, same busy hours, now through the SD-WAN tunnel with your intended voice policy active. The overlay result should be at least as good as the better underlay, and under duplication or FEC it should be better. If overlay numbers are *worse* than the best raw circuit, the tunnel overhead or a misconfigured policy is costing you quality, and you've just learned that before deployment instead of after.

**3. Break things on purpose.** Pull the primary circuit mid-call. Then do the harder test: degrade it without killing it (saturate it with bulk traffic, or add loss with a lab impairment tool if you have one) and watch whether brownout detection actually moves the call, how fast, and whether the transition is audible. A platform that only handles link-down is just an expensive dual-WAN router.

**4. Confirm the paths are actually diverse.** Ask both ISPs about physical routing, and look beyond the last mile: shared upstream backhaul, a common wholesale provider POP, or a single power feed at your building can couple two "diverse" circuits just as effectively as a shared conduit. If you can't establish diversity on paper, assume it doesn't exist and price in a wireless second path.

## When plain dual-WAN failover is all you need

SD-WAN service typically costs several times what a dual-WAN-capable router does, and it adds an ongoing subscription, a management layer, and one more thing that can be misconfigured. That price buys real capabilities, but only if your situation exercises them.

Skip SD-WAN and use ordinary dual-WAN failover when: your primary circuit is genuinely solid and your problem is rare hard outages, not chronic degradation; a few seconds of switchover and dropped active calls during a failover are acceptable; and your call volume is modest. That's Tier 3 in [our failover architecture guide](/blog/voip-failover-architectures), and it serves a huge share of small businesses perfectly well, especially paired with free provider-side call forwarding as a last resort.

Pay for SD-WAN when the specifics apply to you: circuits that go sick more often than they go down, call volumes where a mid-call drop has real cost, multiple sites that can terminate tunnels at both ends, or contractual pressure to demonstrate voice resilience. In those cases the brownout detection, duplication, and session survival are worth real money.

Either way, the deciding evidence is measurement, not the brochure. Two well-chosen circuits with boring failover and honest QoS beat a sophisticated overlay stretched across two bad ones, every time.

---

## How Call Transfer Works in SIP: REFER, Replaces, and NOTIFY

URL: https://voiptest.com/blog/sip-call-transfer-explained
Published: 2026-08-06
Category: Fundamentals
Tags: sip, call-transfer, refer, replaces, troubleshooting, voip

Pressing the transfer button is one button press. What happens underneath is the most involved sequence in everyday SIP, involving a method that does nothing else, an event subscription nobody asked for, and a header whose entire job is to say "forget the call you already have, use this one instead."

It is also, consistently, the feature that breaks first in a mixed-vendor environment. Transfers work perfectly between two identical desk phones and fall apart the moment a different handset, a different PBX, or a [session border controller](/blog/sbc-fundamentals) enters the path. Knowing the message flow is what turns "transfers are broken" into a specific, fixable fault.

This post goes deep on transfer specifically. For how hold, forwarding, and conferencing work alongside it, see [Call Features in SIP](/blog/sip-call-features).

## The three roles

RFC 5589 gives the participants names, and using them saves a lot of confusion, because "the caller" becomes ambiguous the moment a transfer starts:

- **Transferor**: the person who presses transfer. Alice.
- **Transferee**: the person being transferred, who is already on a call with Alice. Bob.
- **Transfer target**: where Bob is being sent. Charlie.

The counterintuitive part, and the thing worth internalising before anything else: **Alice presses the button, but Bob's phone does the work.** Alice does not connect Bob to Charlie. Alice sends Bob an instruction, and Bob's phone places its own call to Charlie. Every transfer failure mode follows from this. If Bob's phone cannot reach Charlie, or does not understand the instruction, the transfer fails no matter how healthy Alice's connection is.

## The REFER method

REFER (RFC 3515) is the mechanism. It means: *place a call to this address on my behalf, and tell me how it goes.*

```
REFER sip:bob@192.168.1.100:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK9921
From: <sip:alice@example.com>;tag=abc123
To: <sip:bob@example.com>;tag=def456
Call-ID: 3848276298220188511@10.0.0.50
CSeq: 4 REFER
Refer-To: <sip:charlie@example.com>
Referred-By: <sip:alice@example.com>
Contact: <sip:alice@10.0.0.50:5060>
Content-Length: 0
```

Two headers carry the meaning. `Refer-To` is the destination, the only genuinely required piece. `Referred-By` (RFC 3892) records who ordered the transfer, which matters for both display purposes and policy: some systems reject a REFER that does not identify its originator.

Note that this REFER travels **inside the existing dialog** between Alice and Bob. Same Call-ID, same tags, incremented CSeq. It is not a new call, it is a new request within the conversation they are already having. In-dialog is the overwhelmingly common case, because it gives Bob's phone the context it needs, but it is not the only one the protocol permits. RFC 3515 explicitly requires a UA to be prepared to receive a REFER outside of any existing dialog. Whether to act on one from a party it is not already talking to is an authorization decision, not a protocol rule, and most implementations sensibly reject an out-of-dialog REFER as a matter of policy.

Bob's phone answers:

```
SIP/2.0 202 Accepted
```

`202 Accepted`, not `200 OK`, and the distinction is deliberate and worth understanding. 202 means "I have received your request and I will act on it," not "it worked." At this moment nothing has been transferred. Bob's phone has merely agreed to try. Treating a 202 as success is the single most common misreading of a transfer trace.

## The NOTIFY subscription nobody asked for

Alice needs to know whether the transfer succeeded. REFER handles this by creating an **implicit event subscription**: by sending the REFER, Alice is automatically subscribed to an `refer` event package describing its progress. She did not send a SUBSCRIBE. It happened as a side effect.

Bob's phone then reports back with NOTIFY messages whose bodies are fragments of SIP responses, content type `message/sipfrag` (RFC 3420):

```
NOTIFY sip:alice@10.0.0.50:5060 SIP/2.0
CSeq: 5 NOTIFY
Event: refer
Subscription-State: active;expires=60
Content-Type: message/sipfrag;version=2.0
Content-Length: 20

SIP/2.0 100 Trying
```

Then, as Charlie's phone starts ringing:

```
Subscription-State: active;expires=60
Content-Type: message/sipfrag;version=2.0

SIP/2.0 180 Ringing
```

And finally:

```
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag;version=2.0

SIP/2.0 200 OK
```

That last one is the transfer actually succeeding. The `Subscription-State: terminated` closes the implicit subscription; there is nothing further to report. Only now can Alice safely tear down her call legs.

This progress stream is the most useful thing in a transfer trace and the most commonly missing. A REFER answered with 202 and then silence tells you Bob's phone accepted the instruction and then either never placed the INVITE or could not reach Charlie. That is a completely different fault from a REFER rejected outright, and the NOTIFY chain is what distinguishes them.

Some implementations suppress the subscription entirely using `Refer-Sub: false` (RFC 4488), typically when a B2BUA is going to handle the outcome itself. Its absence is not automatically a bug, but if you see neither `Refer-Sub: false` nor any NOTIFY, something has gone wrong.

## Blind transfer

Blind (or unattended) transfer is the simple case. Alice does not speak to Charlie first. She sends the REFER shown above, with a bare `Refer-To`, and typically drops her leg to Bob as soon as she gets the 202.

The flow:

1. Alice and Bob are talking
2. Alice sends REFER with `Refer-To: <sip:charlie@example.com>`
3. Bob's phone returns 202 Accepted
4. Bob's phone sends a fresh INVITE to Charlie, including `Referred-By: <sip:alice@example.com>`
5. Bob's phone NOTIFYs Alice with progress
6. Charlie answers, Bob and Charlie are talking
7. Alice's leg is torn down with a BYE

The unresolved question in blind transfer is **what happens when Charlie does not answer**, and the specification does not settle it. Some phones return Bob to Alice if she is still on the line. Some drop Bob entirely, which from the customer's perspective is a hang-up. Some send Bob to Charlie's voicemail, which may or may not be what anyone wanted. If Alice has already hung up (which most phones do immediately), there is nothing to return to regardless.

This is why blind transfers behave inconsistently across a mixed fleet. It is not that one vendor is wrong; the standard genuinely leaves it open. If callers are being dropped on unanswered transfers, the fix is usually configuration on the transferee's device or the PBX, not the network.

## Attended transfer and the Replaces header

Attended (consultative) transfer is where Alice checks with Charlie first, and it needs one more piece of machinery.

1. Alice and Bob are talking (call A)
2. Alice puts Bob on hold: a re-INVITE with `a=sendonly` in the [SDP](/blog/sdp-media-negotiation)
3. Alice calls Charlie. This is call B: a completely separate dialog, its own INVITE, its own Call-ID
4. Alice tells Charlie what the call is about. Charlie agrees to take it
5. Alice sends a REFER to Bob, and this is where it differs

```
REFER sip:bob@192.168.1.100:5060 SIP/2.0
CSeq: 4 REFER
Refer-To: <sip:charlie@192.168.1.200?Replaces=a84b4c76e66710%40host
  %3Bto-tag%3Dxyz789%3Bfrom-tag%3Dabc123>
Referred-By: <sip:alice@example.com>
```

The `Refer-To` now carries an embedded `Replaces` parameter. Decoded, that escaped string is `Replaces: a84b4c76e66710@host;to-tag=xyz789;from-tag=abc123`, the Call-ID and both dialog tags of **call B**, the consultation call between Alice and Charlie.

`Replaces` (RFC 3891) means: *when this INVITE arrives, do not treat it as a new incoming call. Find the dialog it identifies, and substitute this one for it.*

So Bob's phone INVITEs Charlie with a `Replaces` header. Charlie's phone matches it against the live call with Alice, accepts, and swaps the media over. **Charlie's phone never rings a second time.** The audio simply changes from Alice's voice to Bob's. That seamlessness is the entire point of the Replaces mechanism, and it is why an attended transfer feels different from a blind one at the receiving end.

The escaping matters, incidentally. Those `%3B` sequences are semicolons and `%40` is an at-sign, escaped because they are being carried inside a URI inside a header. Implementations that escape this incorrectly produce transfers that fail in ways that look inexplicable until you decode the header by hand.

## Where the transfer actually happens

Everything above describes endpoints talking to each other. Real deployments usually have something in the middle, and this changes what you will see on the wire.

Most hosted platforms put a B2BUA or an SBC between the phones. When Alice sends a REFER, it frequently does not reach Bob at all. The SBC terminates it, and then re-originates the transfer itself, building its own INVITE to Charlie and bridging the legs internally. From Bob's phone's perspective, no transfer occurred; the audio just changed.

This has three practical consequences:

**Where you capture determines what you see.** A capture at the handset may show a clean REFER and 202 while the failure is happening on the far side of the SBC, or show no REFER at all on a transfer that plainly worked. Capture on both sides of the middlebox before concluding anything.

**The platform's REFER support is what counts, not the phone's.** A handset that implements RFC 3515 flawlessly will still fail if the platform in front of it does not relay or re-originate correctly.

**Some trunks forbid REFER outright.** Many carriers will not accept a REFER from the customer side, because it asks them to originate a call leg they cannot bill cleanly. The platform must instead keep the call anchored and bridge it internally, which works, but means the media stays in the provider's path for the life of the call rather than flowing directly.

## Why transfers fail

| What you see | What it means |
|---|---|
| `405 Method Not Allowed` or `501 Not Implemented` to the REFER | The device does not implement REFER. Common on ATAs, older handsets, and stripped-down clients. The PBX must handle the transfer instead |
| `202 Accepted`, then no NOTIFY at all | The instruction was accepted but the INVITE to the target never happened or never got a response. Check whether the transferee can route to the target |
| `481 Call/Transaction Does Not Exist` on the Replaces INVITE | The dialog named in Replaces is gone or never matched. Usually the consultation call was torn down too early, or a B2BUA rewrote the tags so they no longer correspond |
| `603 Decline` or `403 Forbidden` from the trunk | The carrier is refusing to originate the referred leg. Anchor the call on your platform instead of passing REFER upstream |
| Transfer works internally, fails to external numbers | Almost always the trunk. Internal transfers stay inside your PBX; external ones ask the carrier to accept a REFER or a re-INVITE it may not permit |
| The target rings twice on an attended transfer | Replaces was dropped or not understood, so the INVITE was handled as a brand-new call rather than a substitution |
| Transfer completes but audio is one-way | Not a signalling failure. The transfer succeeded and the media path is wrong; see below |

The [SIP response code reference](/tools/sip-codes) covers what each of these codes means outside the transfer context.

## One-way audio after a transfer

This one deserves separating out, because the instinct is to blame the transfer and the transfer is not at fault.

A transfer necessarily renegotiates media. New endpoints, new SDP, new RTP path. If that renegotiation produces a path that works in one direction only, you get a completed transfer where one party cannot hear the other, and the SIP trace looks perfect, because the signalling did exactly what it should.

The usual causes are the usual causes of [one-way audio](/blog/one-way-audio-packet-level) generally: [NAT](/blog/sip-nat-traversal) translating an address that the new SDP advertises incorrectly, a firewall that has pinholes for the original media path but not the new one, or [SIP ALG](/blog/sip-alg-the-setting-that-breaks-everything) rewriting SDP it does not fully understand. The transfer is not causing the fault, it is exposing one that was already there: the original call path happened to work, and the new one does not.

The diagnostic that settles it quickly: compare the `c=` line and media port in the post-transfer SDP against where RTP is actually arriving. If they disagree, the problem is address translation, not transfer.

## Reading a transfer in a capture

When you have a capture and need to determine what happened, work through it in this order:

1. **Find the REFER.** No REFER at all means either a middlebox absorbed it or the phone used a different mechanism entirely. Both are worth knowing immediately.
2. **Check the response.** 202 means accepted. Anything in the 4xx or 5xx range means rejected, and the code tells you why.
3. **Decode Refer-To.** Is there a Replaces parameter? That tells you attended versus blind, regardless of which button the user believes they pressed.
4. **Follow the NOTIFY chain.** The sipfrag bodies are the transfer's own account of itself: 100, then 180, then 200 is a clean transfer. A chain that stops early localises the failure precisely.
5. **Find the new INVITE.** It carries `Referred-By`, and on attended transfers a `Replaces` header. Its response is the real outcome; everything before it is preamble.
6. **If audio is wrong, ignore all of the above** and compare the negotiated SDP with the actual RTP flow.

[Capturing VoIP traffic in Wireshark](/blog/capture-voip-traffic-wireshark) covers getting a usable capture in the first place, and our [PCAP analyzer](/tools/pcap-analyzer) will lay out the dialogs and media streams from a capture file without your having to trace tags by hand.

## What to check first

When transfers are failing in a given environment, the sequence that resolves it fastest:

**Does it fail for everyone, or for specific devices?** Device-specific failures are almost always REFER support or its configuration. Universal failures are the platform or the trunk.

**Internal or external?** External-only failures point at the carrier and how your platform passes transfers upstream.

**Blind or attended?** Attended-only failures point at Replaces handling, usually a B2BUA rewriting dialog identifiers.

**Signalling or audio?** If the parties are connected but cannot hear each other, stop investigating transfer entirely. That is a media path problem that a transfer merely revealed, and it will bite you on other call flows too.

Transfer sits on top of everything else SIP does: dialogs, tags, SDP negotiation, media paths. That is exactly why it breaks first when something underneath is not quite right. Most of the time, a broken transfer is a symptom rather than the disease.

---

*This post expands on the transfer section of [Call Features in SIP: Hold, Transfer, and Forwarding](/blog/sip-call-features), part of [SIP Signaling From the Wire Up](/blog/series/sip-signaling-from-the-wire-up). For how a call gets established in the first place, start with [The First Call Flow: INVITE to BYE](/blog/first-call-flow-invite-to-bye).*

---

## Certificate Management for VoIP: The Expiration Time Bomb

URL: https://voiptest.com/blog/voip-certificate-expiration
Published: 2026-08-04
Category: Technical
Tags: tls, certificates, srtp, voip-security, sip-tls, provisioning

Somewhere in your VoIP deployment right now, a certificate is counting down to zero. Maybe it's the one your PBX presents to desk phones. Maybe it's on the provisioning server that phones check for config updates every night. Maybe it's the client certificate your SIP trunk provider requires for mutual TLS. When it hits zero, nothing dramatic happens: no alarm, no error banner. Phones just quietly stop registering, one by one, over the following hours as their registration timers expire.

That delay is what makes certificate expiration uniquely nasty in VoIP. The failure is decoupled from the cause. The cert expired Saturday at midnight; the phones started dropping off Sunday afternoon; the tickets arrived Monday morning; and nobody on the troubleshooting call is thinking about certificates because "nothing changed over the weekend."

This post maps out where certificates actually live in a VoIP deployment, how each one fails when it expires, why desk phones are a special problem, and what the industry's move to much shorter certificate lifetimes means for how you manage all of it.

## Where certificates live in a VoIP deployment

Most people can name one certificate in their phone system: the HTTPS cert on the admin portal. A real deployment has far more, and each one is a separate expiration clock.

### SIP-TLS between phones, PBX, and provider

If your signaling is encrypted (and per our post on [SIP authentication and signaling security](/blog/sip-authentication-security), it should be), every TLS hop involves at least one certificate. Phones connecting to the PBX over SIP-TLS validate the PBX's certificate. The PBX registering to your trunk provider over TLS validates the provider's certificate. Each validation checks three things: the certificate chains to a trusted root, the hostname matches, and the current date falls within the validity window. Expiration fails the third check, and the TLS handshake dies before a single SIP message is exchanged.

### Mutual TLS on trunks

Some trunk providers and inter-site connections use mutual TLS: not only does your PBX verify the provider's certificate, the provider verifies a client certificate your PBX presents. This doubles the certs to track on that connection, and the client cert is the one that gets forgotten; it doesn't show up in any web-based certificate scanner because nothing browses to it. It only exists inside the TLS handshake of your trunk registration.

### HTTPS provisioning servers

Desk phones fetch their configuration from a provisioning server, almost always over HTTPS. This is how they learn their line registrations, firmware versions, directory settings, and feature keys. The provisioning URL is often checked on boot and then on a schedule; nightly is common. The phone validates the provisioning server's certificate on every fetch, using its own built-in trust store (more on that below).

### Phone firmware trust stores

The phones themselves don't have certificates to expire (unless you deploy client certs to them), but they carry something just as time-sensitive: a trust store of root CA certificates baked into the firmware. That list determines which server certificates the phone will ever accept. On many models it only changes when the firmware changes; some phones do let an administrator import additional CA certificates or take separate trust-store updates, which is worth knowing model by model.

Add these up and a modest 50-phone deployment easily has half a dozen independent certificates plus a hundred-odd embedded trust stores, all capable of breaking calls, and typically zero of them in any monitoring system.

## How SRTP hangs off the TLS layer

Media encryption looks like a separate concern from certificates, but it isn't. As covered in [how SRTP works](/blog/how-srtp-works), the two dominant key exchange methods both lean on TLS.

**SDES** carries SRTP keys inside the SDP body of the SIP signaling. Its entire security model is "the signaling is encrypted with TLS, therefore the keys are protected." When the TLS certificate on the signaling path expires, the TLS session can't be established, the SIP messages carrying the keys never flow, and calls fail at setup. Worse, some PBX configurations fall back to unencrypted transport when TLS fails, at which point calls resume, but your SRTP keys are now traveling in plaintext SDP. The system "works" and your encryption is theater.

**DTLS-SRTP**, mandatory for browser-based calling, performs a certificate-based handshake directly on the media path. Browsers generate short-lived self-signed certificates for this and manage them automatically, so browser-to-browser calls rarely hit expiration issues. But the server-side components that terminate it (SBCs, media gateways, SIP-over-WebSocket edges) hold long-lived DTLS certificates that an admin installed once and forgot. When one expires or the fingerprint in the SDP stops matching the certificate presented in the handshake, the DTLS handshake fails and no media flows in either direction, even though signaling looked fine.

Either way, the pattern is the same: the certificate lives at the TLS layer, but the symptom shows up in the audio.

## The failure modes, in order of confusion

Certificate expiration in VoIP doesn't produce one failure. It produces a family of them, each with its own misleading signature.

### Phones that keep working, until they don't

TLS certificates are validated at handshake time, not continuously. A phone with an established TLS connection to the PBX keeps that connection after the cert expires; nothing re-checks the date mid-session. The failure arrives when the connection resets (a re-registration, a network blip, a phone reboot) and the new handshake fails validation.

Since [SIP registration](/blog/sip-registration) expiry timers are staggered across a fleet, phones drop off gradually. Two phones dead at 9 a.m., ten by noon, most of the office by end of day. A rolling failure like this looks like a network problem or a PBX resource leak. Nobody's first instinct is "check the certificate," because the phones that still work seem to prove the server is fine.

### Silent registration failure

When the handshake fails, the phone can't even send the REGISTER, so the PBX logs show nothing: no auth failure, no error response, just an absence. The phone is the only device that knows why, and desk phones are notoriously terse: a small "no service" icon, maybe a one-line log entry about TLS if you dig into the web UI. From the user's chair, the phone looks normal and inbound calls go to voicemail. If you're working through the [phones-not-ringing checklist](/blog/phones-not-ringing), expired certificates belong on it right after registration status.

### One-way or no audio

Per the SRTP dependency above: a failed DTLS handshake means no media at all; a partial TLS failure in a multi-hop signaling path (say, PBX-to-provider still valid, PBX-to-phone expired, with a fallback in between) can produce calls that connect with [one-way audio](/blog/one-way-audio) or dead air. These are the worst tickets, because the signaling trace looks clean and the actual failure happened at a layer most VoIP troubleshooting never inspects.

### Provisioning that quietly stops

When the provisioning server's certificate expires, phones don't break; they just stop updating. Every nightly config fetch fails silently, and the phone keeps running on its last known config. Nothing is visibly wrong for weeks or months. Then you change a setting centrally and it never lands, or you deploy a firmware update that nobody receives, or a new hire's phone won't provision at all. The fleet has been drifting the whole time, and the drift only becomes visible when you need the provisioning channel to work. Of all the failure modes, this one has the longest gap between cause and detection.

## Desk phones and the embedded trust store problem

Servers are the easy half of the problem. The hard half is the trust store inside every desk phone.

A phone's firmware ships with a list of root CA certificates. If your provisioning or SIP-TLS certificate chains to a root that isn't on that list, the phone rejects it, even if the certificate is brand new and perfectly valid. How that list changes varies by vendor: on many models it only updates with firmware, while others accept administrator-imported CA certificates or separate trust-store updates. A phone whose roots only ship with firmware, running five-year-old firmware, has a five-year-old view of which certificate authorities exist.

The canonical example is the Let's Encrypt root transition. Let's Encrypt originally gained broad compatibility through a cross-signature from IdenTrust's DST Root CA X3. That root expired on September 30, 2021, leaving Let's Encrypt certificates chaining to its own ISRG Root X1, which older devices had never heard of. Devices with stale trust stores started rejecting valid Let's Encrypt certificates overnight. Desk phones, with their long service lives and infrequently applied firmware updates, were exactly the class of device that got burned, and the same class of problem will recur every time a widely used root ages out or a CA changes its chain.

On firmware-only models the trap is circular: the fix for a stale trust store is a firmware update, and firmware is delivered through provisioning, which may be the very thing the phone can no longer connect to. Once such a fleet is on the wrong side of a root transition, you're touching phones by hand or standing up a temporary provisioning endpoint with a certificate the old firmware still trusts. Plan firmware currency (and, where supported, CA-import procedures) as certificate management, because it is.

## The clock is speeding up

If your renewal process is "a calendar reminder and an afternoon of manual work once a year," the industry has already broken it.

In April 2025 the CA/Browser Forum passed ballot SC-081v3, which put publicly trusted TLS *server* certificates on a schedule of shrinking maximum lifetimes: 200 days for certificates issued on or after March 15, 2026 (already in effect), 100 days from March 15, 2027, and 47 days from March 15, 2029. Domain validation reuse periods shrink on the same schedule, down to 10 days in 2029. Certificates from private PKIs and device trust anchors are outside the ballot's scope and follow their own policies.

That means every publicly trusted certificate in your VoIP stack (the provisioning server, the SBC's public interface, the browser-calling gateway) now renews at least twice a year, moving to roughly monthly by 2029. Each renewal is a rotation event that can trip any of the failure modes above. Manual handling doesn't just get tedious at that cadence; it becomes statistically guaranteed to miss one eventually.

Private/internal CAs aren't bound by these limits, and some deployments will respond by moving phone-facing certificates onto an internal CA with longer lifetimes. That's a legitimate choice, but it trades the renewal treadmill for full ownership of the trust store problem, because now you have to get your private root onto every phone.

## What to actually do

None of this requires exotic tooling. It requires treating certificates as operational infrastructure instead of a setup step.

**Inventory every certificate and every trust store.** Walk the deployment and list them: PBX SIP-TLS cert, trunk provider connections (including any mutual TLS client certs), provisioning server, SBC interfaces, DTLS certs on media components, admin portals. Then inventory the other side: phone models, firmware versions, and which roots each firmware trusts. If you can't say which root CA your provisioning cert chains to and whether your oldest phone firmware trusts it, you have a latent outage.

**Monitor expiration, not just uptime.** Certificate checks belong in the same monitoring system as ping and registration counts. Alert at 30 days and again at 7. Monitor the actual TLS endpoints (including SIP-TLS ports, not just HTTPS) because the cert your monitoring sees on port 443 may not be the one your PBX presents on 5061.

**Automate renewal wherever possible.** ACME-based automation is the default answer for anything publicly trusted, and at a 200-day maximum heading to 47, it's effectively mandatory. Where a component can't do ACME natively (many PBXes and SBCs can't), script the deployment step: renew centrally, push the cert, reload the service. Reserve manual renewal for the shrinking set of certs that truly can't be automated, and put those on aggressive alerting.

**Test after every rotation.** A renewed certificate is a changed certificate: new chain, possibly a new intermediate, occasionally a new root. After rotation, confirm phones re-register over TLS, make a real inbound and outbound call, and run a [VoIP quality test](/tools/voip-test) to verify the media path end to end, since DTLS and SRTP failures hide behind healthy-looking signaling. Five minutes of verification after each rotation is what turns certificate management from a time bomb into routine maintenance.

The certificate that takes down your phone system won't announce itself. It's already installed, already trusted, and already expiring. Find it before it finds you.

---

## IPv6 and VoIP: The Transition Nobody Wants to Talk About

URL: https://voiptest.com/blog/ipv6-and-voip
Published: 2026-07-31
Category: Technical
Tags: ipv6, sip, nat, dual-stack, nat64, one-way-audio

The IPv6 transition has been "almost here" for two decades, and for most of the internet it finally, quietly arrived. On March 28, 2026, [Google's adoption measurement](https://www.google.com/intl/en/ipv6/statistics.html) crossed 50% for the first time: half of the users reaching Google did so over IPv6. [APNIC Labs](https://blog.apnic.net/2026/04/28/google-hits-50-ipv6/), which measures capability rather than preference and weights its sample differently, puts worldwide IPv6 capability at roughly 42% as of late April 2026. Those two figures are not in conflict (they measure different things), but it does mean the honest statement names its metric. "Google's user metric crossed 50%" is supportable. "The internet is half IPv6" is not a claim either measurement makes.

VoIP did not get the memo. Production SIP deployments -- trunks, hosted PBX registrations, on-premises systems, the phones on desks -- remain overwhelmingly IPv4. Most VoIP providers do not publish AAAA records for their SIP infrastructure at all. The few that support IPv6 usually treat it as an edge feature terminated at a border element, with everything behind it still speaking IPv4.

This post is about why that gap exists, where the actual breakage lives when IPv6 shows up on a voice network, and what to check when it lands on yours.

## Why VoIP is still IPv4

The short answer: SIP is one of the worst-positioned protocols on the internet for an address-family transition, and nobody involved has a strong incentive to move first.

A web browser's addresses live only in packet headers, where the OS and the network can handle translation transparently. SIP is different in a way regular readers of this blog will recognize from the [NAT traversal post](/blog/sip-nat-traversal): it writes literal IP addresses into the application payload, at multiple layers, and expects them to be reachable by whoever reads them.

Add to that the installed base: deskphones with ten-year lifecycles, PBX software with IPv4 assumptions baked into its NAT-workaround logic, and carrier interconnects certified on IPv4 that will not be re-certified without a commercial reason. Voice is also the service where "it works, don't touch it" carries the most weight, because failures are immediately audible and users escalate them fast. The result is a protocol ecosystem running on the old address family while the networks underneath it turn dual-stack.

## Where the pain actually lives: addresses inside the message

Take any SIP INVITE apart (the [anatomy of a SIP message](/blog/anatomy-of-a-sip-message) post does this line by line) and you find IP addresses in at least three places:

```
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK776asdhds
Contact: <sip:alice@192.0.2.10:5060>
...
c=IN IP4 192.0.2.10
m=audio 49170 RTP/AVP 0
```

The Via header tells responses where to return. The Contact header tells the far end where to send future requests. The `c=` line in the SDP body tells the other endpoint where to send RTP. On an IPv6 call, each of those becomes `IN IP6` with an IPv6 literal. On a dual-stack call, the endpoint has to pick -- and there is no guarantee it picks an address family the other side can reach.

This is the core problem. Signaling and media are negotiated in-band, address by address, and nothing in baseline SIP says "here are both of my addresses, use whichever works for you."

The IETF did try. ANAT (Alternative Network Address Types, RFC 4091 and RFC 4092) defined an SDP grouping mechanism that let an offer carry both an IPv4 and an IPv6 media address so the answerer could choose. It saw almost no deployment outside some IMS profiles, the IETF later recommended against its use, and in practice it is dead. The mechanism that actually solved address-family selection is ICE: gather candidates of both families, run connectivity checks, use what works. That is how browser-based calling handles dual-stack every day without anyone noticing. But classic SIP deskphones and PBXs mostly do not do ICE, so in the SIP world the job falls to a middlebox rewriting addresses and bridging media between families. [SBCs](/blog/sbc-fundamentals) end up as the practical v4/v6 boundary in almost every real deployment, terminating IPv6 on one side and re-originating IPv4 on the other.

## No happy eyeballs for SIP

Web browsers solved the dual-stack client problem years ago with Happy Eyeballs (RFC 8305): try IPv6 and IPv4 nearly in parallel and use whichever connects first, so the user never sees a stall from a broken IPv6 path. It works so well that networks with quietly broken IPv6 mostly go unnoticed by web users.

SIP user agents have no equivalent standard behavior, and most implementations have nothing like it. RFC 3263 tells a UA how to resolve a SIP domain through NAPTR and SRV down to A and AAAA records, but when resolution yields both families, what happens next is implementation-defined. Some phones try AAAA first and wait out a full transaction timeout -- 32 seconds for an unanswered INVITE over UDP with RFC 3261's default timers (Timer B, 64×T1) -- before trying IPv4, if they try at all. Some ignore AAAA records entirely. Some use whichever record the resolver returned first.

This interacts badly with DNS in exactly the ways described in [DNS and VoIP](/blog/dns-and-voip). A provider that publishes both A and AAAA records for its SIP hostname is trusting every customer's phone firmware to handle the pair sensibly. If IPv6 is enabled but broken -- a stale router advertisement, a firewall that permits v6 outbound but mishandles the return path -- phones fail to register or take half a minute to place a call, and the failure is intermittent because it depends on record ordering and cache state. "Some phones work and some don't" is the classic DNS-outage symptom; mixed A/AAAA on a half-working dual-stack network produces the same maddening pattern.

## NAT64, DNS64, and the embedded-literal problem

IPv6-only networks reach the IPv4 internet through NAT64: a translator with a well-known prefix (64:ff9b::/96) that maps IPv4 destinations into IPv6 addresses. DNS64 makes it transparent by synthesizing AAAA records for names that only have A records, pointing at the translator.

For web traffic this works. For SIP it fails in a familiar way, because DNS64 can only rewrite DNS answers. It cannot rewrite the IPv4 literals inside a SIP message. A registrar that returns a Contact with an IPv4 address, an SDP answer whose `c=` line says `IN IP4 203.0.113.5`, a redirect to an IP-literal URI -- none of these pass through DNS, so none get translated. The IPv6-only client is handed an address it has no interface for. Signaling might limp along if it flows through a proxy, but media negotiated by address in the SDP simply has nowhere to go. If [SDP negotiation](/blog/sdp-media-negotiation) lands on an address family the endpoint cannot use, the call connects and the audio does not.

If that failure shape sounds familiar, it should. It is NAT-breaks-SIP all over again: a device in the middle rewrites headers but not payloads, and the payload is where SIP keeps its addresses.

464XLAT (RFC 6877) is the patch that made IPv6-only mobile networks livable. It pairs two distinct elements: a stateless translator on the device (the CLAT) presents an IPv4 interface to applications and translates their traffic to IPv6 before it leaves the phone, and the carrier's stateful NAT64 (the PLAT) translates it back to IPv4 at the far edge. IPv4-only apps -- including SIP clients that write `IN IP4` literals into their SDP -- keep working, because from the app's point of view there is a real IPv4 network. The cost: the PLAT's stateful NAT64 performs NAT-like address and port rewriting, so every NAT behavior you have ever fought is potentially present even though there is no NAT box anywhere on your network diagram.

## The irony

Here is the part that stings. IPv6, fully deployed, eliminates the single largest source of VoIP misery: address translation. No private addresses means no NAT. No NAT means no [one-way audio](/blog/one-way-audio) from unroutable SDP, no rport fix-ups, no SIP ALG mangling your INVITEs. The entire workaround stack documented in the [NAT traversal post](/blog/sip-nat-traversal) exists because IPv4 ran out of addresses; IPv6's whole reason for being (RFC 8200) is that it doesn't. Be precise about what goes away, though: what IPv6 removes is translation, not firewalls or policy. A globally routable address is not automatically reachable: a default-deny stateful firewall still drops unsolicited inbound signaling and media, so keepalives to hold firewall state open and connectivity checks like ICE (RFC 8445) remain useful even with no NAT anywhere.

And yet the transition mechanics recreate the same class of bug in new clothes. Dual-stack lets signaling negotiate over one family while the SDP offers media on the other: one-way or no-way audio, with globally routable addresses on both ends. NAT64 leaves IPv4 literals stranded in message bodies: unreachable media, again. Different decade, same autopsy: the address in the SDP is not an address the other side can send packets to.

## Dual-stack operational reality

If you run voice on a dual-stack network, a few specific things determine whether life is boring or exciting:

**Which family a phone registers over matters.** The registrar stores the Contact from the REGISTER. If the phone registered over IPv6, inbound signaling comes to its IPv6 address, and any element in the inbound path that is IPv4-only needs something to bridge the gap. Registration family effectively pins the call path.

**Signaling family and media family are negotiated separately.** Nothing forces RTP onto the same family the SIP dialog used. A well-behaved endpoint offers media on the family it registered over; not all endpoints are well-behaved, and config options like "prefer IPv6" often apply to one layer and not the other.

**The SBC is the transition plan.** In nearly every deployment that genuinely supports both families, the answer is not endpoint intelligence, it is an [SBC doing interworking](/blog/sbc-fundamentals): IPv6 signaling and media on one leg, IPv4 on the other, with the SBC rewriting Via, Contact, and SDP, and relaying RTP between families. This is the same "terminate and re-originate" trick that solves NAT, applied to the v4/v6 boundary. It works, and it means the "IPv6 support" on your provider's datasheet is usually one box deep.

**Mobile clients already live in this world.** The big US mobile carriers have run IPv6-only or IPv6-mostly data networks with 464XLAT for years -- Akamai's per-network measurements put the major US mobile operators at roughly 74-88% IPv6 traffic. Every softphone on those networks is either speaking IPv6 natively or being carried by the CLAT, so if your users run mobile SIP clients on carrier data, you have IPv6 traffic today. Any weirdness that only reproduces "on cellular but not on Wi-Fi" deserves an address-family suspect.

## Practical guidance

If IPv6 is enabled on a network where you are deploying voice -- or it just got enabled underneath you -- work through this list:

1. **Find out what your provider actually supports.** `dig AAAA` their SIP hostnames, and check the SRV targets from [their DNS chain](/blog/dns-and-voip) too. No AAAA records means your phones should never attempt IPv6 SIP to them, and any IPv6-related failure is local resolution or firmware behavior, not the provider.
2. **Check what your endpoints do with dual-stack answers.** On a test phone, watch a capture during registration: does it try AAAA first, how long does it wait before falling back, does it fall back at all? This single behavior explains most "phones take forever to register on the new network" tickets.
3. **Confirm signaling and media use the same family.** In a capture, compare the family the dialog runs over with the `c=` line in the SDP. A mismatch without an ICE-capable or SBC-mediated path is a one-way-audio incident waiting for its first call.
4. **On IPv6-only or NAT64 networks, assume embedded literals break.** Any config field holding a raw IPv4 address -- outbound proxy set by IP, provisioning URLs, STUN server IPs -- can fail where a hostname would have been rescued by DNS64 or the CLAT.
5. **Test the path, not the checkbox.** Run an end-to-end quality test from the actual network segment, on the address family the phones will really use. A [browser-based VoIP test](/tools/voip-test) uses ICE and will happily pick whichever family works -- useful for proving the network path, but remember your deskphones lack that adaptability.

And then there is the folk remedy: **just disable IPv6**. It is the first suggestion in every forum thread, and on a dual-stack network with broken v6 it genuinely makes symptoms vanish, which is why it persists. Understand what it costs. You are masking the misconfiguration, so it will return on the next device that cannot disable IPv6. You give up the better path where the provider supports v6 end to end -- a path with no NAT and none of its failure modes. And on IPv6-only access networks the option does not exist: on a 464XLAT mobile network, "disabling IPv6" means disabling the network. The remedy has an expiry date.

## The bottom line

Google's user measurement crossed 50% in 2026, and VoIP remains the conspicuous holdout for structural reasons: SIP embeds addresses everywhere, and the fix-it-in-the-middle machinery is being rebuilt for the v4/v6 boundary quietly inside SBCs rather than in endpoints. The endgame is worth wanting -- native IPv6 voice deletes the address-translation problem class, even if stateful firewalls keep ICE and keepalives employed. Getting there means a long stretch where calls cross an address-family boundary somewhere, and every crossing is a place where the address in the message and the address on the wire can disagree. You know what that sounds like: a call that connects, and silence. Test the paths you actually use, on the families they actually use, before your users do it for you.

*Related reading: [NAT Traversal: Why SIP and NAT Don't Get Along](/blog/sip-nat-traversal) for the IPv4 version of this misery, and [SBC Fundamentals](/blog/sbc-fundamentals) for the box doing the interworking in the meantime.*

---

## RTCP: How Your Phones Already Measure Call Quality

URL: https://voiptest.com/blog/rtcp-how-phones-measure-quality
Published: 2026-07-28
Category: Technical
Tags: rtcp, rtp, call-quality, mos, monitoring, voip-fundamentals

Nearly every business phone on your network already runs a quality measurement system on its calls. It counts lost packets, estimates jitter, computes round-trip time, and often produces a MOS estimate: continuously, passively, using a protocol that has been part of the VoIP standard since the beginning. Most people troubleshooting call quality never look at any of it.

That protocol is RTCP, the RTP Control Protocol, defined in the same document as RTP itself (RFC 3550). This post covers what RTCP actually reports, how its numbers are calculated (and why they differ from what a packet capture or speed test shows), where the reports end up, and how to use them when a quality complaint lands on your desk.

## RTP carries the audio, RTCP carries the report card

When a VoIP call sets up, the SDP negotiation allocates a port for RTP, the stream of small, frequent packets carrying encoded audio. By convention, RTP uses an even port and RTCP takes the next odd port up: RTP on 10000, RTCP on 10001. (Modern browser media stacks usually multiplex RTCP onto the same port as RTP instead, per RFC 5761, which simplifies NAT traversal, but the port-plus-one convention still dominates desk phones and SIP trunks.)

RTCP is deliberately lightweight. RFC 3550's classic guideline allots about 5% of session bandwidth to RTCP in aggregate, with a reporting interval that scales with the number of participants and a recommended minimum of about five seconds, randomized so endpoints don't report in lockstep. On a typical two-party call that works out to a quality report roughly every five seconds per direction, but that's the default behavior, not a guarantee: implementations can reduce RTCP bandwidth, suppress reports, or omit RTCP entirely. That cadence matters later: RTCP gives you a sampled, periodic view, not a per-packet one.

Two report types do most of the work:

- **Sender Reports (SR)** come from an endpoint that is actively sending media. An SR contains the sender's wall-clock (NTP-format) timestamp, the corresponding RTP timestamp, and counts of packets and octets sent, plus reception statistics for the streams it's receiving.
- **Receiver Reports (RR)** come from endpoints that are only receiving (or are between SRs). They carry the same reception statistics without the sender information.

RTCP also carries SDES items (notably CNAME, a canonical identifier that ties streams together) and BYE packets, but the reception report blocks inside SRs and RRs are where the quality data lives.

## What's inside a reception report block

Each report block describes one incoming stream, identified by its SSRC. Five fields matter for quality work.

**Fraction lost.** An 8-bit fixed-point number: the fraction of packets lost since the previous report, times 256. A value of 26 means roughly 10% loss over the last reporting interval. This is your short-term loss signal: a call that was clean for four minutes and then hit a bad patch shows it here.

**Cumulative number of packets lost.** A 24-bit running total for the whole stream, defined as packets expected minus packets received. It's a signed value: duplicate packets can push it negative, which surprises people the first time they see it.

**Extended highest sequence number received.** The low 16 bits are the highest RTP sequence number seen; the high 16 bits count how many times the sequence number has wrapped. This is what makes the "expected packets" arithmetic possible on a 16-bit sequence space.

**Interarrival jitter.** Covered in detail next, because it's the most misunderstood number in the block.

**LSR and DLSR.** Two timestamp fields that enable round-trip time measurement without synchronized clocks. Also covered below.

### How the RFC 3550 jitter estimator actually works

The jitter number in an RTCP report is not "the variation in packet arrival times" in any raw sense. It's the output of a specific estimator, and knowing how it behaves changes how you read it.

For each pair of packets i and j, the receiver computes the difference in *relative transit time*:

```
D(i,j) = (Rj − Ri) − (Sj − Si)
```

where R is the arrival time at the receiver and S is the RTP timestamp the sender stamped on the packet. Absolute clock offset between the two endpoints cancels out of the subtraction; only the *change* in transit time survives. If every packet took exactly as long as the last one, D is zero.

The estimator then smooths the absolute value of D with a 1/16 gain, applied on every arriving packet:

```
J(i) = J(i−1) + (|D(i−1,i)| − J(i−1)) / 16
```

Each new observation moves the running estimate one-sixteenth of the way toward itself. That's an exponential moving average with a long memory, chosen deliberately by the RFC's authors as a noise-reduction filter.

Two consequences follow. First, **a brief jitter spike barely registers.** A single packet delayed 100ms in an otherwise smooth stream nudges the estimate up by about 6ms, then it decays back down. The event that made a word drop out may be nearly invisible in the reported number. Second, **the reported value is a snapshot**, not a mean or a max; it's whatever the estimator read when the report was generated.

This is why RTCP jitter routinely disagrees with other tools. Analyzing a [packet capture in Wireshark](/blog/capture-voip-traffic-wireshark) gives you per-packet interarrival deltas, where you can see the individual 100ms outlier that the estimator smoothed away. A speed test measures neither: it reports throughput on bulk TCP transfers, which says nothing about the timing consistency of small paced UDP packets. And one more unit trap: RFC 3550 jitter is expressed in RTP timestamp units, not milliseconds. For an 8kHz codec like G.711, divide by 8 to get milliseconds; a reported jitter of 160 is 20ms. Some phone GUIs do the conversion for you, some don't, and a misread here is a factor-of-eight error.

If you want the grounding on what jitter and loss actually do to a call, that's covered in [Latency, Jitter, and Packet Loss: The Details](/blog/latency-jitter-packet-loss-details). This post is about the measurement plane: where those numbers come from.

### Round-trip time without synchronized clocks

The LSR/DLSR mechanism is a genuinely elegant piece of protocol design. Here's the problem: two endpoints want to measure round-trip time, but their clocks aren't synchronized and never will be.

The solution: when endpoint A sends a Sender Report, it includes its own NTP-format timestamp. Endpoint B, when it later sends a report back, echoes the middle 32 bits of that timestamp in the **LSR** (last SR) field and puts the time it held onto it (the delay between receiving A's SR and sending its own report) in the **DLSR** (delay since last SR) field, in units of 1/65536 of a second.

When A receives the report at time T (by its own clock), the round trip is:

```
RTT = T − LSR − DLSR
```

Every term is either measured on A's clock or is a duration B measured locally. B's absolute clock never enters the calculation. No NTP sync, no GPS, no assumptions: just a reflected timestamp and an honest accounting of the turnaround delay.

## RTCP-XR: the extended reports

The basic RFC 3550 statistics tell you the network delivered packets late or not at all. They don't tell you what the listener heard, because that depends on what the endpoint's jitter buffer and concealment algorithms did with the damage. RTCP Extended Reports (RFC 3611) close that gap.

RTCP-XR defines several report block types, but the one that matters for voice is the **VoIP metrics block** (block type 7). It includes:

- **Loss rate and discard rate**, separately. Discards are packets that arrived but too late (or too early) for the jitter buffer to use them: invisible to network-level loss counters, but identical to loss from the listener's perspective.
- **Burst and gap metrics**: burst density, gap density, burst duration, and gap duration. A *burst* is a period of high-density loss/discard; a *gap* is the quiet stretch between bursts. The boundary is set by a parameter called Gmin (16 by default): losses separated by fewer than Gmin received packets belong to the same burst.
- **Round-trip delay and end-system delay**, the latter covering the endpoint's own contribution: jitter buffer, codec, and processing delay.
- **Jitter buffer statistics**: nominal, maximum, and absolute maximum delay, plus whether the buffer is adaptive.
- **Signal, noise, and echo return loss levels.**
- **Quality estimates**: an R-factor and MOS scores, MOS-LQ (listening quality) and MOS-CQ (conversational quality, which folds in delay). If you want to build intuition for how R-factor and network impairments map to MOS, our [MOS Explorer](/tools/mos-explorer) lets you turn the knobs interactively.

The burst/gap distinction is the most operationally valuable part. Average loss is a misleading statistic: 1% loss spread evenly across a call is nearly inaudible after concealment, while the same 1% concentrated into two three-second bursts makes the caller ask you to repeat yourself twice. Burst density distinguishes these cases; a fraction-lost field averaged over five seconds mostly can't. [Understanding VoIP Packet Loss](/blog/understanding-voip-packet-loss) covers why loss distribution matters more than the headline percentage.

## Where the reports actually go

RTCP reports are exchanged between the two ends of the media stream, so in the first instance the data lives on the endpoints themselves. In practice it surfaces in several places:

**Phone web GUIs.** Many business desk phones expose per-call RTCP statistics in their web interface: current call stats on a live call, and often a log of recent calls. This is the fastest place to look when one user complains.

**PBX call detail records.** Many PBX platforms attach quality statistics to CDRs, or generate separate call quality records alongside them, typically one per call leg.

**Provider dashboards.** Hosted VoIP providers aggregate RTCP (and XR, where available) from their edge into per-customer quality dashboards. When your provider says "we're seeing packet loss on your side," this is usually the data behind that claim.

**SIP PUBLISH collectors.** RFC 6035 defines a standard way for endpoints to ship quality summaries off-device: a SIP PUBLISH request with the `vq-rtcpxr` event package, carrying an `application/vq-rtcpxr` body summarizing the call's XR metrics. Endpoints can send a session report at call end, interval reports during the call, and alert reports when a metric crosses a threshold. Many desk phone firmwares and PBX platforms support this, feeding centralized quality collectors. If you run more than a handful of phones and aren't collecting these, you're leaving a free monitoring system switched off.

## The practical catches

RTCP is genuinely useful, but there are traps.

**It fails the same way RTP fails.** RTCP flows over UDP on a port adjacent to the media (or muxed with it). The same NAT and firewall problems that cause [one-way audio](/blog/one-way-audio-packet-level) also eat RTCP, sometimes asymmetrically, so one side has statistics and the other reports nothing. An endpoint showing zero RTCP received isn't measuring a perfect network; it's measuring a blocked port, or a far end that simply doesn't send RTCP, which RFC 3550 permits and some implementations choose.

**SBCs terminate and regenerate it.** Session border controllers that anchor media typically terminate RTCP on each leg and generate their own reports outward. The statistics your phone sees then describe the path *to the SBC*, not the end-to-end path. Often that's useful (it localizes problems to a leg), but "the far end reports no loss" may only mean the SBC-to-far-end leg is clean.

**Encryption applies here too.** When a call uses [SRTP](/blog/how-srtp-works), the control channel is protected by its counterpart SRTCP (also RFC 3711). SRTCP makes authentication mandatory and encryption optional per-packet, so on an encrypted call you can't just read quality reports out of a packet capture on a middle hop; you need the stats from a device that holds the keys, i.e., the endpoints or the SBC.

**XR is opt-in at both ends.** The good stuff (MOS estimates, burst density, jitter buffer discards) only flows if both endpoints implement RFC 3611 and it's enabled in their configuration. Plenty of deployments negotiate plain RTCP only, and plenty of phones support XR but ship with it disabled. If your quality dashboard shows loss and jitter but no MOS or burst data, this is usually why.

## Using RTCP when troubleshooting

The practical workflow: when a quality complaint comes in, pull the RTCP statistics from the phone or the PBX *before* forming a theory. The endpoints were watching the call while it happened; their report blocks tell you whether the problem was loss or late arrival (discards), whether it was bursty or smeared, which direction it affected, and roughly when in the call it occurred. That's enough to decide whether you're chasing a LAN problem, a WAN problem, or a far-end problem, before you've captured a single packet.

Remember the estimator's limits while you read the numbers: smoothed jitter hides short spikes, five-second reporting intervals hide sub-second events, and units may or may not be converted. When the RTCP data points at a timing problem but won't localize it, that's when a targeted [packet capture](/blog/what-packet-capture-tells-you) earns its setup cost.

The other half of the workflow is correlation with active testing. RTCP is passive: it can only describe calls that already happened. An active test generates known traffic on demand, so you can reproduce problem conditions and measure them cleanly. If the phones' RTCP history shows bursty loss every afternoon, run a [VoIP quality test](/tools/voip-test) during the problem window and compare: matching results confirm a network path issue, while a clean active test alongside ugly RTCP numbers points back at the endpoints, their LAN segment, or the far end. Passive reporting tells you something is wrong; active testing tells you whether it's still wrong right now, and from where.

Your phones have been filing quality reports on every call, all along. Start reading them.

---

## What a Session Border Controller Does (and Whether You Need One)

URL: https://voiptest.com/blog/sbc-fundamentals
Published: 2026-07-24
Category: Technical
Tags: sbc, session-border-controller, sip-trunking, voip-security, nat-traversal, sip

Ask five VoIP engineers what a session border controller is and you will get five overlapping but different answers: it's a firewall for SIP, it's a NAT fixer, it's a protocol translator, it's a demarcation point. All of them are right, because an SBC is a bundle of functions that all happen to live at the same place in the network: the border, where your voice traffic meets someone else's.

The name is unhelpfully abstract, so here is the concrete version. An SBC is a back-to-back user agent (B2BUA; RFC 7092 catalogs the breed) that sits between two networks and terminates every SIP session on one side, then originates a new session on the other. Every message crosses the SBC's own SIP stack, and the SBC owns the state of every call crossing it. Every other SBC feature falls out of that one architectural decision, but how far each session is rewritten, whether media is anchored and relayed or released, and whether anything is transcoded are product and policy choices, not automatic properties of every call.

This post covers what those features actually are, why an SBC is categorically different from a firewall with SIP ALG switched on, and (the question most people are really asking) whether your deployment needs one at all.

## The six jobs of an SBC

These are the functions the B2BUA architecture makes possible. Real deployments enable them selectively: each one below is applied (or not) per trunk, per peer, or per policy.

### Topology hiding

Because the SBC terminates and re-originates every session, the outside world only ever sees the SBC. Your PBX's private IP, your internal extension numbering, your Via and Record-Route header chains, the SDP addresses of your phones: none of it leaks past the border. The SBC rewrites all of it.

This matters for two reasons. Security is the obvious one: attackers who can't see your internal topology can't target it directly, and reconnaissance scans hit a hardened purpose-built device instead of your PBX. The less obvious reason is operational: your carrier sees one stable, predictable signaling peer no matter how much you rearrange things behind it. Replace the PBX, renumber the LAN, move to a new SIP platform: the trunk configuration on the carrier side never changes.

### NAT traversal, done properly

SIP was designed in an era before NAT was everywhere, and it embeds IP addresses in message bodies where NAT devices can't see or rewrite them. The result is the classic family of symptoms (registrations that mysteriously expire, calls that connect with no audio) covered in detail in our guide to [SIP and NAT traversal](/blog/sip-nat-traversal).

An SBC solves this from the far end, which is the only place it can be solved reliably. When a phone behind NAT registers through an SBC, the SBC notices that the addresses inside the SIP message don't match the addresses the packets actually arrived from, and it simply uses the real ones. For media, it does the same thing with RTP latching: rather than trusting the address advertised in the SDP, it waits for the first RTP packet to arrive and locks onto that source. It also keeps NAT pinholes alive, typically by forcing short registration intervals toward the outside while caching registrations so your PBX or softswitch isn't hammered with a re-REGISTER every 30 seconds.

No STUN configuration on every endpoint, no guessing at router keepalive behavior, no per-device workarounds. The border device absorbs the problem.

### Protocol normalization and interop

SIP is a standard the way English is a standard: everyone speaks it, nobody speaks it identically. One vendor sends DTMF as `telephone-event` RTP payloads (RFC 4733, which obsoleted RFC 2833, though "2833 DTMF" survives as vendor shorthand), another expects SIP INFO. One PBX requires a session timer refresh via UPDATE, the carrier only supports re-INVITE. Headers arrive in unexpected order, with nonstandard parameters, or subtly malformed in ways that one stack tolerates and another rejects.

An SBC sits in the middle and translates. Header manipulation rules rewrite, insert, and strip whatever each side needs to see. Transport interworking converts between UDP, TCP, and TLS, so your carrier can require encrypted signaling while your legacy PBX only speaks UDP. DTMF interworking converts between signaling methods. When you swap carriers or upgrade the PBX, interop problems get fixed with a rule on the SBC instead of a firmware ticket with a vendor.

### A security boundary that understands SIP

A conventional firewall sees SIP as UDP packets on port 5060. It can allow them or block them, and that is roughly the extent of its insight. An SBC parses every message and makes decisions at the SIP layer, which changes what kinds of attacks it can absorb.

Anything exposing SIP to the public internet gets scanned continuously: SIPVicious and its descendants probe for open PBXs around the clock, looking for extensions to brute-force and trunks to pump fraudulent traffic through. An SBC recognizes scanner signatures and drops them silently. It rate-limits registration attempts per source and dynamically blacklists addresses that fail authentication repeatedly, which blunts both credential stuffing and registration floods. It rejects malformed messages that might crash or exploit a softer SIP stack behind it. And it can terminate TLS and SRTP at the edge, giving you encrypted trunks without requiring every internal element to support them.

None of this replaces the basics: strong SIP credentials, sane dial plan permissions, and toll fraud limits still matter, as covered in [SIP authentication and security](/blog/sip-authentication-security). The SBC is the layer that keeps the flood outside so those inner defenses are rarely tested.

### Transcoding

When the two sides of a call can't agree on a codec, the SBC can convert between them in real time: G.711 on the LAN, G.729 across a constrained WAN link, or Opus toward a browser-calling gateway. On hardware SBCs this runs on dedicated DSP resources; on software SBCs it consumes CPU, and it is usually the single biggest factor in how many concurrent sessions a given box can handle. Transcoding also adds a few milliseconds of latency and a lossy re-encode per conversion, so the best transcoding strategy is to configure codec priorities so it rarely happens; but when an endpoint and a carrier genuinely have no codec in common, the SBC is what keeps the call from failing outright.

### Call admission control

An SBC counts sessions and enforces limits: per trunk, per peer, per direction, or by estimated bandwidth. If your internet connection comfortably carries 30 concurrent G.711 calls, the SBC can cap sessions at 30 so call number 31 gets rejected cleanly with a busy signal, instead of being admitted and degrading the audio of all 31 calls at once. It protects the PBX the same way, absorbing bursts that would otherwise overload the softswitch behind it. Rejecting one call politely beats degrading every call silently.

## An SBC is not a firewall with SIP ALG

It is tempting to file the SBC next to the SIP ALG feature on your router, since both claim to "handle SIP through NAT." Resist the temptation. They are opposite philosophies.

SIP ALG is a passthrough hack: the firewall snoops on packets in transit and rewrites the addresses it believes it understands. In practice, ALG implementations are chronically buggy: they rewrite the wrong fields, mangle authenticated messages, break when SIP arrives over TCP or TLS, and can't be debugged because they modify traffic invisibly. The predictable results are dropped registrations, failed transfers, and [one-way audio](/blog/one-way-audio). We have written about this at length in [SIP ALG: the setting that breaks everything](/blog/sip-alg-the-setting-that-breaks-everything), along with a [router-by-router guide to disabling it](/blog/sip-alg-router-guide).

An SBC is the purpose-built version of what ALG gestures at. As a B2BUA, it doesn't rewrite packets in flight; it terminates the session, holds complete state, and generates a fresh, correct session on the other side. It is a full SIP endpoint with a real parser, maintained by a vendor whose entire product lives or dies on SIP correctness, not a checkbox feature bolted onto a firewall by a team that ships routers.

So the practical rule: SIP ALG should be off, essentially always. An SBC should be deployed when the situation actually calls for one, which brings us to the real question.

## Do you actually need one?

### Hosted VoIP seats: usually no

If your phones register directly to a hosted provider (RingCentral, Zoom Phone, a hosted PBX, any cloud platform), the provider already operates carrier-grade SBCs at their edge, and your handsets are designed to register through NAT to them. Adding your own SBC on-site mostly adds cost and another thing to misconfigure.

Your responsibilities in this model are local network hygiene: SIP ALG disabled, NAT UDP timeouts that outlast registration intervals, and QoS on your uplink. Get those right and hosted seats behind a competent provider just work. A large multi-site enterprise might still put SBCs in front of hosted service for survivability or policy enforcement, but that is the exception.

### SIP trunking into an on-prem PBX: often yes

The calculus flips when you run [SIP trunks](/blog/sip-trunking) into a PBX you operate. Now your PBX *is* the network edge. It terminates carrier signaling directly, it is exposed to whatever the internet sends at port 5060, and every interop quirk between the carrier's SIP dialect and your PBX's becomes your problem to solve inside PBX config files.

An SBC in front of that PBX gives you the security boundary, the topology hiding, the interop layer, and clean NAT handling in one demarcation point. It is also frequently mandatory rather than optional: Microsoft Teams Direct Routing, for instance, requires a certified SBC between your trunks and Teams; there is no supported way around it. For a small office with a single trunk and a well-patched PBX behind a strict firewall, you can operate without one and many do. But the more trunks, carriers, and inbound call volume you have, the faster the SBC pays for itself in avoided fraud and avoided 2 a.m. interop debugging.

### Enterprises and carriers: always

Any organization interconnecting with multiple carriers, running its own softswitch infrastructure, selling voice service, or peering SIP with other organizations deploys SBCs as a matter of course. At that scale the SBC is not a nice-to-have; it is the interconnect architecture. Nobody exposes a softswitch directly to a peer's network.

## Hardware, software, or SBCaaS

**Hardware appliances**: AudioCodes, Ribbon, Oracle (the former Acme Packet line), and Cisco's CUBE running on router platforms are the names you will encounter most. Dedicated DSPs make them the strongest option for heavy transcoding, and carriers still buy chassis-based systems for interconnects. Rough cost: entry units for a small trunk start in the low four figures; carrier-grade platforms run into six figures.

**Software SBCs**: the same vendors ship their SBCs as virtual machines or containers, typically licensed per concurrent session, from hundreds to a few thousand dollars at small scale. On the open-source side, Kamailio or OpenSIPS paired with RTPengine can be assembled into most of an SBC's function set for nothing but engineering time, a legitimate path if you have SIP expertise in-house, and a trap if you don't, because you become the vendor.

**SBCaaS**: cloud-hosted SBC capacity billed per session per month, a category that grew rapidly on the back of Teams Direct Routing. No hardware, no patching, fast deployment, and the economics usually win below a few dozen concurrent sessions. The tradeoff is that your media now hairpins through the provider's cloud region, which adds a network leg to every call.

## Whichever path you take, test the path

An SBC adds a hop to your signaling and, because it relays or transcodes media, a hop to your audio as well. A misconfigured SBC can introduce the very problems it exists to solve: added latency from a badly placed cloud region, jitter from an undersized VM, clipped audio from an overloaded transcoding pool.

So treat the SBC path like any other network path: measure it. Run a [VoIP quality test](/tools/voip-test) from behind the SBC before cutover and again after, and compare latency, jitter, and packet loss. If the numbers degrade meaningfully after inserting the SBC, something in its sizing or placement is wrong, and it is far cheaper to find that during deployment than during your busiest calling hour.

*For the network problems an SBC exists to solve, start with [SIP and NAT traversal](/blog/sip-nat-traversal) and [SIP ALG: the setting that breaks everything](/blog/sip-alg-the-setting-that-breaks-everything). For securing the SIP layer itself, see [SIP authentication and security](/blog/sip-authentication-security).*

---

## VoIP Failover in Practice: 5 Architectures Compared

URL: https://voiptest.com/blog/voip-failover-architectures
Published: 2026-05-30
Category: Guides
Tags: failover, redundancy, business-continuity, sip-trunking, sd-wan, disaster-recovery

Your internet will go down. The question is not if, but what happens to your phone calls when it does. The answer depends on how much downtime your business can tolerate and how much you are willing to spend to prevent it.

This guide ranks five failover architectures from simplest to most resilient. Each tier is a real, deployable solution with specific cost and complexity tradeoffs. Pick the one that matches your actual business requirements: not every business needs tier 5, and tier 1 is dramatically better than nothing.

For the detailed explanation of what happens to VoIP during an internet outage, see [What Happens to Your Phones When the Internet Goes Down](/blog/what-happens-to-phones-when-internet-goes-down). For the broader redundancy discussion, see [Redundancy and Failover: When One Connection Isn't Enough](/blog/redundancy-failover).

## Tier 1: Call forwarding to mobile

**Cost:** $0 beyond existing service
**Switchover time:** typically 30-120 seconds (provider-specific)
**What you keep:** Inbound calls answered
**What you lose:** IVR, call routing, extensions, voicemail, outbound calling from business numbers

This is the "something is better than nothing" tier. Configure your VoIP provider or hosted PBX to forward all inbound calls to a designated mobile phone when your phones lose registration. Most providers support this as a failover rule or "find me / follow me" setting.

When the internet goes down, your phones stop refreshing their registrations, but the registrar's binding persists until its expiry interval runs out (RFC 3261), so the provider only notices as fast as its detection method allows: a lapsed registration, INVITEs that go unanswered, or active monitoring like OPTIONS pings. Providers that offer failover routing typically trigger it 30-120 seconds after detecting the loss, but both the mechanism and the timing are provider-specific; confirm yours and measure it. Once triggered, calls forward to the configured mobile number. Callers hear ringing instead of fast busy. Someone answers.

**Setup:** Log into your VoIP provider's portal. Find the failover or forwarding settings for your main number. Set a mobile number as the failover destination. Set the timeout to the shortest available (30-60 seconds). Test it by unplugging your router.

**Limitations:** Only works for inbound calls. Callers who dialed specific extensions or reached your IVR will get forwarded to a single mobile number with no routing. Outbound calls go from your personal mobile number, not your business number. Call recording, voicemail transcription, and other PBX features are unavailable.

This is better than dead phones. For many small businesses, it is sufficient.

## Tier 2: Cellular backup connection (LTE/5G)

**Cost:** $30-100/month for cellular data plan + $100-300 for LTE failover device
**Switchover time:** 10-60 seconds
**What you keep:** Full phone system functionality
**What you lose:** Call quality may degrade; bandwidth is limited; not suitable for high call volumes

Add a cellular modem or an LTE failover router to your network. When the primary internet connection fails, the router switches traffic to cellular. Your phones re-register over the cellular connection, and calls resume.

**Setup:** Many business routers (Ubiquiti, Fortinet, Cradlepoint, Peplink) support a USB LTE modem or a built-in cellular radio as a WAN failover. Configure the cellular connection as the secondary WAN with automatic failover. Set the failover detection to ping-based (more responsive than waiting for the interface to go down).

**Considerations:** Cellular bandwidth is shared and variable. A single LTE connection can typically support 5-15 simultaneous VoIP calls depending on conditions. Run our [VoIP quality test](/tools/voip-test) over the cellular connection to verify quality before you need it in an emergency. Test during business hours, not at midnight when the tower is idle.

Cellular latency is higher than wired (30-80 ms typical), which is fine for VoIP. Jitter can be variable, especially on congested towers. The [bandwidth calculator](/tools/bandwidth-calculator) will tell you how many concurrent calls your cellular bandwidth can support.

**Important:** Some cellular plans deprioritize data after a threshold or during network congestion. Make sure your plan is suitable for business use.

## Tier 3: Dual WAN with automatic failover

**Cost:** Second ISP connection ($50-500/month depending on type) + compatible router
**Switchover time:** 5-30 seconds
**What you keep:** Full phone system, full bandwidth
**What you lose:** Brief interruption during switchover; existing calls may drop

Two independent internet connections from different providers, ideally using different last-mile technology (fiber primary, cable backup, or fiber primary, LTE backup). The router monitors both connections and switches automatically when the primary fails.

**Setup:** Connect both ISP connections to your dual-WAN router. Configure health checks (ping to a reliable external target every 5 seconds). Set the primary and secondary WAN interfaces. Configure [QoS](/blog/qos-practical-config) on both connections to prioritize VoIP.

**The key word is "independent."** Two connections from the same ISP using the same last-mile infrastructure do not give you real redundancy. If the fiber cut that took down your primary also serves your backup, both go down together. Use different providers, different technologies, or both.

The switchover interruption depends on your router and configuration. Some routers (Peplink, Fortinet with SD-WAN) can switch in under 5 seconds. Others take 15-30 seconds. Active calls during the switchover will likely drop because the phone's SIP registration changes IP addresses. Calls established after the switchover work normally.

**For critical environments,** pair dual WAN with the call forwarding from Tier 1 as an additional safety net. If both connections fail simultaneously (building power outage affecting both ISPs), calls still forward to mobile.

## Tier 4: SD-WAN with active-active connections

**Cost:** $200-800/month for SD-WAN service + two ISP connections
**Switchover time:** Near-zero (sub-second for some platforms)
**What you keep:** Active calls may survive the failover
**What you lose:** Higher cost and complexity

SD-WAN (Software-Defined Wide Area Network) goes beyond simple dual-WAN failover. It actively manages traffic across multiple connections simultaneously, making real-time decisions about which path to use for each packet. (What SD-WAN genuinely does for voice quality, as opposed to what the marketing claims, is [its own discussion](/blog/voip-sd-wan-reality-check).)

For VoIP, the advantages over traditional dual-WAN:

**Per-packet path selection.** SD-WAN measures latency, jitter, and packet loss on each connection in real time. VoIP packets are automatically routed over the connection with the best quality, not just the one marked "primary."

**Faster failover.** Because SD-WAN is already monitoring both paths, it detects degradation before a complete outage. If the primary connection's jitter spikes above acceptable levels, traffic shifts to the backup before calls start sounding bad.

**Active calls may survive.** Some SD-WAN platforms (Peplink SpeedFusion, Fortinet SD-WAN) can maintain SIP sessions across a path change by managing the session state. This is not guaranteed, and it depends on the VoIP provider and configuration, but it is possible.

**Quality-based routing.** Even when both connections are working, SD-WAN routes VoIP over the better path. If your fiber has a brief quality issue, voice traffic moves to cable temporarily, then moves back when fiber recovers. This happens without manual intervention and often without users noticing.

**Setup:** Deploy an SD-WAN appliance (or configure SD-WAN features on a compatible router). Connect both ISP connections. Define application policies that prioritize VoIP traffic and set quality thresholds (maximum acceptable jitter, packet loss) that trigger path switching.

## Tier 5: Geo-redundant SIP trunks with DNS failover

**Cost:** $500-2,000+/month (two trunk providers, potentially two sites)
**Switchover time:** Near-zero for inbound; seconds for outbound
**What you keep:** Everything, including active inbound call paths
**What you lose:** Significant cost and operational complexity

This is the architecture for businesses where a missed call has serious consequences: medical practices, emergency services, financial trading desks, high-volume sales operations.

**Inbound:** Your phone numbers are configured with multiple SIP trunk providers. DNS SRV records point to both providers. If the primary trunk provider is unreachable, inbound calls route to the secondary. Alternatively, the number provider maintains a failover route that redirects to a backup trunk if the primary does not answer the INVITE within a timeout.

**Outbound:** Your PBX is configured with two trunk registrations. If the primary trunk fails to register or starts rejecting calls, the PBX falls over to the secondary trunk automatically.

**Geographic redundancy:** For the most critical deployments, the PBX itself is replicated across two sites (or hosted in two cloud regions). Active-passive or active-active, depending on the platform. If Site A goes down entirely (building fire, regional power grid failure), Site B picks up all traffic.

This is complex to implement and maintain. It requires coordination between multiple providers, careful DNS configuration, and regular testing. But it provides resilience against failures that lower tiers cannot handle: trunk provider outages, regional internet disruptions, and physical site loss.

## Choosing the right tier

| Factor | Tier 1 | Tier 2 | Tier 3 | Tier 4 | Tier 5 |
|--------|--------|--------|--------|--------|--------|
| Monthly cost | $0 | $30-100 | $100-500 | $400-1,300 | $1,000+ |
| Switchover time | 30-120s | 10-60s | 5-30s | &lt;5s | Near-zero |
| Active calls survive | No | Maybe | No | Maybe | Yes (inbound) |
| Protects against ISP outage | Partial | Yes | Yes | Yes | Yes |
| Protects against building outage | Yes | No | No | No | Yes |
| Protects against trunk provider outage | No | No | No | No | Yes |
| Complexity | Minimal | Low | Moderate | Moderate | High |

Most businesses land at Tier 2 or Tier 3. Cellular backup gives you real failover for a modest monthly cost. Dual WAN is better for businesses with consistently high call volumes that need full bandwidth on the backup path.

Tier 1 should be configured regardless of which higher tier you choose. It is free and it covers the worst case (complete site failure) that the network-level failover solutions do not address.

## Test your failover

Failover that has never been tested is not failover. It is hope. Once a quarter:

1. Disconnect the primary internet connection
2. Time the failover: how long until phones re-register and calls work?
3. Make inbound and outbound test calls through the backup path
4. Run a [VoIP quality test](/tools/voip-test) over the backup path to verify it can handle your call volume
5. Reconnect the primary and verify everything fails back correctly

Document the results. If the failover takes longer than expected or calls do not work over the backup, fix it now, not during an actual outage.

*For the detailed technical background on what happens during an outage, see [What Happens to Your Phones When the Internet Goes Down](/blog/what-happens-to-phones-when-internet-goes-down). For connection redundancy fundamentals, see [Redundancy and Failover: When One Connection Isn't Enough](/blog/redundancy-failover).*

---

## VoIP Quality Testing: How to Get Real Numbers Instead of 'Calls Sound Bad'

URL: https://voiptest.com/blog/voip-quality-testing-guide
Published: 2026-05-29
Category: Guides
Tags: voip-testing, mos-score, jitter, packet-loss, troubleshooting, diagnostics

"The calls sound bad." This is where most VoIP troubleshooting starts, and it is where too many investigations stall. The user thinks the calls sound bad. IT thinks the network is fine. The ISP thinks it is the VoIP provider. The provider thinks it is the ISP. Nobody has numbers. Everybody has opinions.

The way out is measurement. Not a speed test: a VoIP quality test that measures the specific metrics voice traffic depends on. With real numbers, you can diagnose the problem, prove where it is, and verify that your fix worked.

## Why speed tests fail for VoIP

A speed test answers one question: how much data can your connection move per second? It does this by opening multiple TCP connections and pouring data through them as fast as possible. The result is a throughput number in megabits per second.

VoIP does not work like this. A single phone call sends roughly 50 small UDP packets per second, each carrying 20 milliseconds of audio. The total throughput is roughly 87 Kbps per direction for G.711 at 20 ms packets on Ethernet; the exact figure moves with headers and encapsulation. The speed test's 500 Mbps result is irrelevant: you could make thousands of simultaneous calls with that bandwidth.

What matters is what happens to those 50 packets per second:

- Did they all arrive? ([Packet loss](/blog/understanding-voip-packet-loss))
- Did they arrive on time? ([Latency](/blog/latency-jitter-packet-loss-details))
- Did they arrive at consistent intervals? ([Jitter](/blog/what-is-jitter-and-why-it-matters))

Speed tests do not measure any of these. They use TCP (which retransmits lost packets) over a short burst (which may not capture intermittent quality issues). A connection can pass a speed test with flying colors and be terrible for VoIP.

For more on this gap, see [500 Mbps and Your Calls Still Sound Terrible](/blog/bandwidth-doesnt-mean-quality).

## The metrics that matter

One note before the numbers: the bands below are operating targets: practical planning thresholds drawn from common field experience, not pass/fail lines defined by any standard. Where the real boundaries sit for your calls depends on the codec, the packetization interval, forward error correction and concealment behavior, and whether impairment arrives evenly or in bursts. Set explicit targets, write them down, and hold your tests to them.

### Jitter

The variation in the time between consecutive packet arrivals. If VoIP packets should arrive every 20 ms but actually arrive at 15 ms, 28 ms, 12 ms, 35 ms intervals, that variation is jitter. Its audible effect is indirect: jitter hurts calls through the playout buffer, as added delay and late packets discarded as if lost.

- **Under 15 ms:** Excellent. Calls will be crystal clear.
- **15-30 ms:** Good. The jitter buffer on the phone can compensate.
- **30-50 ms:** Marginal. You may hear occasional choppiness, especially during pauses.
- **Over 50 ms:** Poor. Calls will sound robotic, choppy, or have gaps.

### Packet loss

The percentage of packets that never arrive. VoIP uses UDP, which does not retransmit. A lost packet is a lost packet: that 20 ms of audio is gone, whatever the codec. What differs is how well concealment (PLC) papers over the gap and whether FEC can rebuild it, which is why distribution matters as much as the percentage: 1% scattered randomly across a call conceals far better than the same 1% concentrated into two-second bursts.

- **Under 0.5%:** Excellent. Not perceptible.
- **0.5-1%:** Good. Barely noticeable on most calls.
- **1-3%:** Marginal. Audible as occasional clicks, gaps, or brief dropouts.
- **Over 3%:** Poor. Calls are hard to follow. Significant audio gaps.

### Latency (one-way delay)

The time for a packet to travel from sender to receiver, one-way, which is half the round-trip figure a ping shows only if the path is symmetric. This determines conversational delay: how long after you finish a sentence before the other person hears it. The familiar 150 ms figure comes from ITU-T G.114, a transmission-planning reference: it is a commonly cited one-way planning boundary, not a point where audio suddenly fails, and the conversational effect depends on total mouth-to-ear delay and echo control.

- **Under 100 ms:** Excellent. Conversation feels natural.
- **100-150 ms:** Good. Slightly noticeable but acceptable.
- **150-200 ms:** Marginal. You start talking over each other.
- **Over 200 ms:** Poor. Conversation is awkward. Long pauses and interruptions.

### MOS (Mean Opinion Score)

A computed estimate of subjective call quality on a scale from 1 (unusable) to 5 (perfect). Ours comes from the ITU-T G.107 E-model, a transmission-planning model that works from delay and loss impairments. Jitter is not a direct model input; it enters through the buffer delay and late-packet discards it causes. Be clear about the method when you quote a MOS: a G.107 estimate, a P.863/POLQA objective measurement, and a P.800 subjective listening panel are different instruments, not interchangeable numbers. In practice, narrowband VoIP calls max out around 4.4 due to codec limitations.

- **4.0-4.4:** Good to excellent.
- **3.5-4.0:** Acceptable. Occasional quality issues.
- **3.0-3.5:** Noticeable degradation. Callers will complain.
- **Below 3.0:** Poor. Calls are difficult.

For a deeper dive, see [MOS Scores Explained: The Number Behind Call Quality](/blog/understanding-mos-scores).

## The testing methodology

Running a VoIP quality test once tells you what conditions are like right now. Running it systematically tells you whether your network can support voice calls reliably.

### Baseline test

Run the test with the network as idle as possible. This is your best-case scenario. If the baseline shows problems, the network has a fundamental issue: bad routing, a degraded circuit, or a misconfigured device.

Run our [VoIP quality test](/tools/voip-test) from the location and device type that will be making calls. Use a wired Ethernet connection for the baseline to eliminate [Wi-Fi jitter](/blog/home-office-voip-checklist) as a variable.

### Loaded test

Run the test while the network is under typical load. This is the test that reveals real-world quality. Have your team working normally: email, cloud applications, video calls, file transfers. Better yet, run the test during the time of day when call quality is worst (often mid-afternoon; see [Call Quality Is Fine in the Morning But Bad in the Afternoon](/blog/afternoon-call-quality)).

Compare the loaded test to the baseline. If quality degrades significantly under load, the network needs [QoS](/blog/qos-practical-config) or the connection needs more headroom.

### Comparative tests

Run tests from different locations and connection types to isolate the problem:

- **Wired vs. Wi-Fi** from the same location: isolates wireless issues
- **Inside VPN vs. outside VPN**: isolates VPN-related quality problems
- **Different times of day**: isolates time-dependent issues like ISP congestion
- **Different locations** on the same network: isolates per-site issues

Each comparison eliminates variables and narrows the problem. If wired and Wi-Fi both show high jitter, the problem is upstream. If only Wi-Fi shows high jitter, the wireless link is the issue. If morning is fine and afternoon is bad, it is a congestion problem.

### Before-and-after tests

The most powerful use of VoIP quality testing is validating changes. Made a network change? Implemented QoS? Upgraded the internet connection? Disabled SIP ALG?

Run a test before the change and after. The numbers tell you whether the change had an impact, and how much. This is how you prove that the $2,000 firewall upgrade or the switch to a [dedicated internet connection](/blog/dedicated-internet-access) was worth it.

## Using the results

### Diagnosing the problem

| Symptom | Likely metric | Investigation |
|---------|--------------|---------------|
| Choppy or robotic audio | High jitter (>30 ms) | Check [QoS](/blog/office-network-qos), [bufferbloat](/blog/bandwidth-doesnt-mean-quality), Wi-Fi |
| Brief audio dropouts | Packet loss (>1%) | Check network congestion, cable quality, ISP circuit |
| Talking over each other | High one-way latency (>150 ms) | Check routing, VPN overhead, geographic distance |
| Calls fine internally, bad externally | All metrics degrade on external calls | Problem is WAN connection or ISP path |
| Quality worse in afternoon | Metrics degrade at specific times | [Bandwidth saturation](/blog/afternoon-call-quality), ISP congestion |

### Presenting results to others

When you need to escalate to your ISP, provider, or management, the test results are your evidence. Include:

- **The numbers.** Jitter, packet loss, latency, MOS for each test.
- **Timestamps.** When each test was run. This lets the ISP correlate with their monitoring.
- **Comparison.** Loaded vs. unloaded, before vs. after, wired vs. wireless.
- **Your operating targets.** State the thresholds you hold the connection to (and that they are your targets), and how far off the results are.

"Our VoIP quality test at 2:30 PM showed 45 ms jitter, 2.3% packet loss, and a MOS of 3.1. The same test at 7 AM showed 8 ms jitter, 0.1% packet loss, and MOS 4.3. The degradation coincides with peak business hours" is a fundamentally different conversation than "the calls sound bad in the afternoon."

### Ongoing monitoring

VoIP quality is not a one-time check. Networks change, ISP conditions change, and new devices or applications can introduce problems at any time. Consider:

- Running a test from each major location weekly
- Testing after any network change
- Testing whenever users report quality issues (capture the data while the problem is happening)

For MSPs managing multiple client sites, see [Monitoring VoIP Quality Proactively](/blog/msp-proactive-monitoring) for a systematic approach.

Use the [bandwidth calculator](/tools/bandwidth-calculator) alongside your test results to verify that your connection can handle your call volume. If the math says you have plenty of bandwidth but the quality test shows degradation, the problem is not capacity; it is the quality of the connection or the network between the phones and the internet.

*For the pre-deployment version of this methodology, see [Testing VoIP Before You Deploy: A Pre-Flight Checklist](/blog/voip-pre-flight-checklist). For understanding the metrics in detail, see [Latency, Jitter, and Packet Loss: The Details](/blog/latency-jitter-packet-loss-details).*

---

## QoS for VoIP in Practice: Configuration That Actually Works

URL: https://voiptest.com/blog/qos-practical-config
Published: 2026-05-27
Category: Guides
Tags: qos, dscp, network, ubiquiti, fortinet, meraki, voip-quality

QoS (Quality of Service) tells your network to treat voice packets differently from everything else. The concept is simple: when the network is busy, VoIP packets go first. The implementation varies by vendor and the details matter.

This is the hands-on companion to [Quality of Service: Telling Your Network What Matters](/blog/quality-of-service-explained) and [QoS: Telling Your Network What Traffic Matters Most](/blog/office-network-qos). Those posts explain the concepts. This one walks through the configuration on the equipment you are likely to have.

## The fundamentals in 30 seconds

VoIP phones mark their packets with DSCP 46 (Expedited Forwarding). Your network equipment needs to do two things:

1. **Trust the marking.** Do not strip the DSCP value at the switch or router.
2. **Act on it.** Put DSCP 46 packets in a priority queue so they are transmitted first when there is contention.

That is the entire idea. The vendor-specific configurations below implement exactly this.

## Where QoS actually works (and where it does not)

Before diving into configuration, set the right expectation: **QoS only operates on your own network.** DSCP is only a marking, and every network domain your packets cross decides independently whether to trust it: your ISP will typically ignore, remark, or strip customer markings at its edge, as will the networks beyond it. This is not a bug or a misconfiguration; it is how DiffServ works across trust boundaries. If ISPs honored customer-set priority markings blindly, every customer would mark all their traffic as high priority and the system would collapse.

This means the configurations below protect your voice traffic from congestion between your phones and your router's WAN interface. Once packets enter your ISP's network, they travel the same best-effort path as everything else. If your VoIP quality problems originate on the internet leg (between your ISP and your VoIP provider), QoS on your end will not help.

So why bother? Because local network congestion is one of the most common and most fixable causes of VoIP quality problems. When someone in the office starts a large upload, a cloud backup kicks in, or Windows Update downloads a feature update, your router's outbound queue fills up. Without QoS, voice packets wait in line behind bulk data. With QoS, voice packets skip the line. The internet path is the same either way, but the local leg is clean.

If your quality problems persist after implementing QoS, the issue is likely upstream. A [dedicated internet connection](/blog/dedicated-internet-access) helps not because of end-to-end QoS, but because DIA provides consistent, uncontested bandwidth with SLA-backed performance. The connection itself is better, which matters more than packet markings.

## DSCP values for VoIP

The common markings, and where each one comes from:

| Traffic type | DSCP value | DSCP name | Notes |
|-------------|-----------|-----------|-----------------|
| Voice media (RTP) | 46 | EF | Expedited Forwarding, RFC 4594's recommendation for telephony media; a low-latency, low-loss per-hop behavior (often, but not necessarily, implemented as a priority queue) |
| Voice signaling (SIP) | 40 | CS5 | RFC 4594's recommendation for telephony signaling |
| Voice signaling (SIP), alternative | 24 | CS3 | Common Cisco/enterprise convention: fine when your QoS design maps it consistently, but not RFC 4594's value |
| Video conferencing | 34 | AF41 | Assured Forwarding, high priority |
| Default (everything else) | 0 | BE | Best Effort |

Most VoIP phones mark RTP at DSCP 46 out of the box; the signaling default varies by vendor (CS3 is common, some use CS5). Either signaling value works as long as every device in the path classifies it the same way. Check your phone's admin interface to confirm. If the phone is not marking correctly, fix it at the phone; it is easier than having the network remark traffic.

## Ubiquiti (UniFi / EdgeRouter)

### UniFi: Smart Queues (the easy way)

Smart Queues use SQM (Smart Queue Management) with fq_codel to manage bufferbloat. This is the simplest effective QoS for most networks.

In the UniFi controller:

1. Go to **Settings > Internet** (or **Settings > Networks > WAN**)
2. Enable **Smart Queues**
3. Set the **Download** and **Upload** speeds to approximately 85-90% of your actual connection speed. This is critical: the queue only works if it is the bottleneck, not the ISP link. If you set it too high, packets queue in the modem instead of the router, and SQM cannot manage them.

Run a speed test to determine your actual throughput, then set Smart Queues to 85% of that number.

Smart Queues do not prioritize VoIP specifically; they prevent any single flow from monopolizing the link and keep latency low for all traffic. For most small offices, this is sufficient because it eliminates [bufferbloat](/blog/bandwidth-doesnt-mean-quality) which is the primary cause of VoIP quality degradation under load.

### EdgeRouter: Strict priority queue

For more control, EdgeRouter supports traffic shaping with priority queues:

```
set traffic-policy shaper VOIP-QOS bandwidth 100mbit
set traffic-policy shaper VOIP-QOS default bandwidth 80%
set traffic-policy shaper VOIP-QOS default queue-type fair-queue

set traffic-policy shaper VOIP-QOS class 10 bandwidth 20%
set traffic-policy shaper VOIP-QOS class 10 ceiling 100%
set traffic-policy shaper VOIP-QOS class 10 priority 0
set traffic-policy shaper VOIP-QOS class 10 queue-type strict-priority
set traffic-policy shaper VOIP-QOS class 10 match VOIP ip dscp 46

set interfaces ethernet eth0 traffic-policy out VOIP-QOS
```

Replace `100mbit` with your actual upload speed (at 85-90%). Replace `eth0` with your WAN interface. This creates a strict priority queue for DSCP 46 traffic that can burst to 100% of the link but is guaranteed 20%.

## Fortinet (FortiGate)

FortiGate firewalls support traffic shaping through the GUI and CLI.

### GUI method

1. Go to **Policy & Objects > Traffic Shapers**
2. Create a new shaper:
   - Name: `VoIP-Priority`
   - Type: Shared
   - Maximum bandwidth: your WAN upload speed
   - Guaranteed bandwidth: 20% of your WAN upload speed
   - Priority: High

3. Go to **Policy & Objects > Traffic Shaping Policy**
4. Create a new shaping policy:
   - Source: your VoIP VLAN/subnet
   - Destination: any
   - Service: SIP, H.323, or a custom service group including UDP ports 5060 and 10000-20000
   - Shaper: `VoIP-Priority`
   - Reverse Shaper: `VoIP-Priority`

### CLI method with DSCP matching

```
config firewall shaper traffic-shaper
    edit "VoIP-Priority"
        set guaranteed-bandwidth 20000
        set maximum-bandwidth 100000
        set priority high
    next
end

config firewall shaping-policy
    edit 1
        set srcintf "lan"
        set dstintf "wan1"
        set tos 0xB8
        set tos-mask 0xFC
        set traffic-shaper "VoIP-Priority"
        set traffic-shaper-reverse "VoIP-Priority"
    next
end
```

The TOS value `0xB8` with mask `0xFC` matches DSCP 46 (EF). Adjust the bandwidth values to match your connection.

## Cisco Meraki MX

Meraki's traffic shaping is configured in the dashboard.

1. Go to **Security & SD-WAN > SD-WAN & Traffic Shaping**
2. Under **Global bandwidth limits**, set appropriate per-client limits
3. Under **Traffic shaping rules**, create a rule:
   - Definition: **Custom expression** matching your VoIP subnet or DSCP marking
   - Or use **VoIP & video conferencing** as the application category
   - Priority: **High**
   - Per-client bandwidth limit: Do not limit (or set generously)

4. Under **Uplink configuration**, enable **Load balancing** if you have multiple WAN links and select a preference for VoIP traffic

Meraki's approach is less granular than Fortinet or Ubiquiti CLI; it works at the application layer rather than DSCP level. For most deployments, selecting the VoIP application category and marking it high priority is sufficient.

## Switch configuration: Trust DSCP

Your router QoS is only effective if the switches between the phones and the router preserve the DSCP markings. Many switches rewrite DSCP to 0 by default on untrusted ports.

### Ubiquiti UniFi switches

In the UniFi controller, go to **Settings > Networks**. If you have a dedicated VoIP VLAN, ensure it is configured correctly. UniFi switches trust DSCP markings by default on all ports, so typically no additional configuration is needed.

### Cisco / Meraki switches

On Cisco IOS switches, trust DSCP on the voice VLAN ports:

```
interface range GigabitEthernet1/0/1-24
 mls qos trust dscp
```

Meraki MS switches trust DSCP by default when a voice VLAN is configured on the port.

### HP / Aruba switches

```
interface range 1-24
 qos trust dscp
```

The general principle: any switch port connected to a VoIP phone should trust DSCP markings so the priority tags survive from the phone all the way to the router.

## Verifying it works

Configuration without verification is hope, not QoS. Here is how to confirm your QoS is actually protecting voice traffic:

### The load test

1. Run our [VoIP quality test](/tools/voip-test) with the network idle. Record the jitter, packet loss, and latency.
2. Generate heavy load: start a large file upload, run a speed test on another device, or have someone stream video in both directions.
3. Run the VoIP quality test again during the heavy load.

**Without QoS:** the second test will show significantly higher jitter and latency. You may see packet loss.

**With QoS working correctly:** the second test should show similar results to the first. Voice quality should remain stable even while the network is saturated with other traffic.

If the results are the same loaded vs. unloaded, your QoS is working. If quality degrades under load, something is not configured correctly: check that DSCP is being trusted on all switches in the path, that the shaper speed is set correctly (85-90% of actual), and that the QoS policy is applied to the right interface.

### DSCP verification

Capture packets at the router's WAN interface and verify that VoIP packets still carry DSCP 46. If they are arriving at the router as DSCP 0, something in the path (a switch, another router) is stripping the marking. Trace the path and find where the marking is being lost.

Use the [bandwidth calculator](/tools/bandwidth-calculator) to right-size your QoS reservation. Calculate how many concurrent calls you expect at peak and the per-call bandwidth for your codec. Your guaranteed VoIP bandwidth should cover that number with some headroom.

*For the conceptual foundation, see [Quality of Service: Telling Your Network What Matters](/blog/quality-of-service-explained). For the network context, see [QoS: Telling Your Network What Traffic Matters Most](/blog/office-network-qos).*

---

## Your Home Office VoIP Checklist: Why Wi-Fi 6 Does Not Fix Call Quality

URL: https://voiptest.com/blog/home-office-voip-checklist
Published: 2026-05-26
Category: Guides
Tags: remote-work, wifi, home-office, voip-quality, troubleshooting, jitter

You have Wi-Fi 6. You have a mesh system with three nodes. Your speed test shows 400 Mbps. And your VoIP calls still sound choppy every afternoon.

The problem is not your internet speed. It is not your ISP (probably). It is not your VoIP provider. It is the wireless hop between your laptop and your router, and no amount of Wi-Fi marketing will fix it.

## Why Wi-Fi is fundamentally different for VoIP

Wi-Fi is a shared medium. Every device connected to your access point competes for airtime. The router can only talk to one device at a time on each channel (Wi-Fi 6 improved this with OFDMA, but the improvement for small, frequent packets like VoIP is modest). When your laptop sends a VoIP packet, it waits for its turn, transmits, and hopes it got through. If it did not, it retransmits.

This process introduces two things VoIP hates:

**Variable latency (jitter).** On a wired Ethernet connection, packets leave your device at a consistent rate and arrive at the router with consistent timing. On Wi-Fi, the time between sending a packet and it actually being transmitted varies depending on channel contention, interference, and retransmissions. This variation is [jitter](/blog/what-is-jitter-and-why-it-matters), and it is the primary reason VoIP sounds worse on Wi-Fi.

**Retransmission delays.** Wi-Fi has its own retransmission mechanism at the link layer. If a packet is corrupted (interference from a microwave, a neighbor's network, Bluetooth devices), Wi-Fi retransmits it automatically. This adds delay. The VoIP application does not know the packet was retransmitted; it just sees a packet that arrived 30 ms later than expected.

A speed test does not reveal these problems because speed tests measure throughput over several seconds. The brief delays and jitter events that ruin VoIP quality are averaged out. The speed test shows 400 Mbps. The calls sound terrible. Both things are true simultaneously.

For the full technical comparison, see [Wired vs. Wi-Fi for VoIP: Why the Cable Still Wins](/blog/wired-vs-wifi-for-voip).

## The mesh system problem

Mesh Wi-Fi systems are excellent for coverage. Every room gets a signal. The problem for VoIP is that every hop through the mesh adds latency.

When your laptop connects to a satellite mesh node in your office, and that node connects wirelessly to the primary node in the living room, and the primary node connects to the internet, your VoIP packets are making two wireless hops before they even reach the router. Each hop adds latency and jitter, and there is no fixed per-hop number: the cost depends on the RF environment, how busy the airtime is, whether the mesh has a dedicated backhaul radio (or a wired backhaul), and the hardware itself. On a clean dedicated backhaul a hop might measure a millisecond or two; on a congested shared-radio backhaul we have measured hops adding tens of milliseconds.

Even in the good case, the added one-way delay eats into the mouth-to-ear delay budget that ITU-T G.114 uses for transmission planning, and in the bad case, the jitter from each hop is what pushes your connection into audibly-bad territory.

Mesh systems also periodically steer devices between nodes, moving your connection from a distant node to a closer one (or vice versa) based on signal strength. During the handoff, there is a brief interruption. For web browsing, you never notice. For a phone call, it is an audible glitch.

### The fix for mesh

Connect your work machine to the **primary** mesh node (the one connected to the modem/router) via Ethernet. Most mesh nodes have at least one Ethernet port. This eliminates the wireless hops for your traffic and gives you the best quality the mesh system can provide.

If your office is too far from the primary node for an Ethernet run, connect to the nearest satellite node with Ethernet. This eliminates at least one wireless hop and significantly reduces jitter.

## The $15 fix

A USB Ethernet adapter costs $10-15. A short Ethernet cable costs $5. Plugging your laptop into your router (or the nearest mesh node) via Ethernet eliminates wireless jitter entirely. It is the single most effective improvement you can make for home office VoIP quality.

This is not a theoretical improvement. Run our [VoIP quality test](/tools/voip-test) on Wi-Fi, then plug in Ethernet and run it again. Compare the jitter numbers. The difference is usually striking: in a typical measured example, Wi-Fi jitter in the tens of milliseconds drops to 1-3 ms on Ethernet. Your own numbers will vary with the RF environment and load, which is exactly why measuring both is worth the five minutes.

If a wired connection to the router is not physically practical (wrong room, no Ethernet port nearby), consider:

**Powerline Ethernet adapters.** These use your home's electrical wiring to carry Ethernet. Quality varies by home wiring age and condition, but even a mediocre powerline connection typically has lower jitter than Wi-Fi. Not as good as a direct Ethernet run, but better than wireless for VoIP.

**MoCA adapters.** If your home has coaxial cable (from cable TV), MoCA adapters carry Ethernet over the coax. These are generally excellent: low latency, low jitter, high throughput. If you have a coax outlet near your desk and near your router, this is a strong option.

## If you must use Wi-Fi

Sometimes wired is not an option. If you are on Wi-Fi, these adjustments help:

**Use the 5 GHz or 6 GHz band.** These bands have more available channels and less interference from household devices. Most modern routers have band steering that does this automatically, but verify your device is actually connecting on 5/6 GHz, not falling back to 2.4 GHz.

**Reduce channel contention.** Every device on your Wi-Fi competes for airtime. During calls, reduce the load: pause large downloads, ensure cloud backups are not running, and be aware of other household members streaming video. Video streaming in particular generates steady traffic that competes with your VoIP packets.

**Check for interference.** Microwaves, baby monitors, older cordless phones, and some Bluetooth devices operate on 2.4 GHz and cause interference. If calls get worse when someone is in the kitchen, the microwave is probably the culprit (on 2.4 GHz).

**Sit closer to the access point.** Signal strength matters. A strong signal means fewer retransmissions and less jitter. If you can see the router from your desk, you are in good shape. If you are two walls away, the signal degradation adds jitter.

**QoS on the router.** If your router supports QoS, configure it to prioritize VoIP traffic. On the wireless side this maps to Wi-Fi Multimedia (WMM) access categories, which give voice frames statistical priority in the contention for airtime: priority, not a reservation, so a saturated channel still hurts. See [Quality of Service: Telling Your Network What Matters](/blog/quality-of-service-explained) for how QoS works. Some routers (Ubiquiti, pfSense) support SQM (Smart Queue Management) which is particularly effective at reducing [bufferbloat](/blog/bandwidth-doesnt-mean-quality).

## The ISP-provided router problem

Many home offices use the router provided by the ISP. These are often mediocre: limited QoS options, weak Wi-Fi radios, aggressive SIP ALG enabled by default, and firmware that is rarely updated.

If your VoIP quality is consistently bad and you have tried the above steps, the ISP router may be the bottleneck. Options:

**Bridge mode.** Put the ISP router in bridge mode and use your own router behind it. You gain control over QoS, Wi-Fi settings, and SIP ALG (which you should [disable](/blog/sip-alg-router-guide)).

**Replace it entirely.** Some ISPs allow you to use your own modem/router. This gives you full control. Check compatibility with your ISP first.

## Test your setup

Run our [VoIP quality test](/tools/voip-test) from your home office during a typical workday. Run it at different times (morning, mid-afternoon, late afternoon) to see if quality changes through the day. If it does, you are likely seeing [bandwidth contention](/blog/afternoon-call-quality) from household or neighborhood usage.

Test on both Wi-Fi and Ethernet (if you can) to isolate whether the problem is the wireless link or the internet connection itself. If jitter is high on both wired and wireless, the problem is upstream: your ISP or the internet path. If jitter is high on Wi-Fi but low on Ethernet, the wireless link is the issue and the fixes above will help.

Use the [bandwidth calculator](/tools/bandwidth-calculator) to verify your connection can handle your concurrent call count plus normal household internet usage. Remember: bandwidth is rarely the actual problem, but if three people are on video calls simultaneously and someone is uploading to cloud storage, even a 100 Mbps connection can get congested enough to cause VoIP quality issues.

*For the technical details on jitter and why it matters for voice, see [What Is Jitter and Why Does It Wreck Your Calls?](/blog/what-is-jitter-and-why-it-matters). For IT teams monitoring remote worker quality, see [VoIP Quality for Remote Teams: What IT Should Be Monitoring](/blog/voip-quality-for-remote-teams). And if you use a company softphone from home, check that your E911 location record points to your home address, not the office.*

---

## Why Caller ID Still Lies in 2026

URL: https://voiptest.com/blog/stir-shaken-reality-2026
Published: 2026-05-25
Category: Industry
Tags: stir-shaken, caller-id, robocalls, spam, attestation, compliance

The STIR/SHAKEN framework was mandated by the FCC with a clear goal: stop caller ID spoofing. Carriers were required to implement it. Deadlines were set. Compliance was enforced. The promise was that caller ID would finally mean something: that when your phone showed a number, you could trust that the call actually came from that number.

It is 2026. YouMail's Robocall Index, a third-party estimate extrapolated from its own call-blocking user base, put US robocall volume above 29 billion calls last year, barely budged from the year before. Not every call in that count is unwanted (the same automated paths deliver school closures and prescription reminders), but FCC and FTC complaint data tell the same story: the problem has not gone away. Your phone still rings with spoofed numbers. The "Scam Likely" label appears on legitimate business calls. And caller ID still cannot be trusted.

STIR/SHAKEN is not a failure of technology. It is a failure of expectations. Understanding what it actually does, and what it does not do, explains the gap.

## What STIR/SHAKEN actually does

STIR (Secure Telephone Identity Revisited) and SHAKEN (Signature-based Handling of Asserted information using toKENs) form a framework for cryptographically signing caller ID information. When a call is placed:

1. The originating carrier examines the call and assigns an attestation level
2. The carrier signs the caller ID information with a digital certificate
3. The signature travels with the call through the network
4. The terminating carrier verifies the signature and uses the attestation level to inform call handling

The three attestation levels:

**A: Full Attestation.** The carrier knows the customer and confirms the customer has the right to use the calling number. This is the highest level of trust. Your carrier knows your business, knows the phone numbers assigned to your account, and is willing to vouch that you are who you claim to be.

**B: Partial Attestation.** The carrier knows the customer but cannot verify the right to use the specific calling number. This might apply when a business uses a SIP trunk that passes through caller ID set by the customer's PBX. The carrier knows the trunk customer but does not control which number the PBX puts in the From header.

**C: Gateway Attestation.** The carrier received the call from another network (often an international gateway) and cannot verify anything about the caller or the number. The carrier is just passing it along.

This is a verification framework, not a blocking framework. It authenticates the calling identity the originating provider *asserts*, carried in a SIP Identity header (RFC 8224), and tells the receiving carrier what level of confidence that provider has in it. What the receiving carrier does with that information is up to them. And because the signature rides in SIP signaling, it only survives on IP call segments: a call that transits a legacy TDM segment, or an international network that does not participate, arrives with no signature to verify.

## Why it has not stopped robocalls

### Problem 1: Attestation does not mean legitimacy

A-level attestation means the carrier vouches for the caller's right to use the number. It does not mean the caller is not a spammer. A business can legitimately own a phone number, have full attestation on their calls, and use that number to robocall thousands of people in violation of the TCPA. The signature is valid. The call is still illegal.

STIR/SHAKEN authenticates the asserted identity. It does not verify intent, and a signed, fully attested robocall is no more legal than an unsigned one.

### Problem 2: Gateway calls bypass the system

A substantial share of illegal robocall traffic enters the US through international gateways, enough that the FCC created dedicated gateway-provider obligations to address it, though the exact share depends on whose dataset and which denominator you use. These calls receive C-level attestation at best: the US carrier that accepts the call from the international network cannot verify the caller or the number. Many of these calls carry no STIR/SHAKEN signature at all because the originating country does not participate in the framework or the path includes non-IP segments that cannot carry the signature.

The spammers know this. Moving call origination offshore puts them outside the STIR/SHAKEN system entirely. The framework works best for domestic, carrier-to-carrier calls: exactly the calls that were least likely to be spoofed in the first place.

### Problem 3: SIM farms and legitimate numbers

The latest evolution in robocalling uses SIM farms: racks of physical SIM cards from legitimate mobile carriers. Each SIM is a real phone number with a real carrier account. Calls from these SIMs receive A-level attestation because the carrier genuinely assigned the number. The spammer burns through SIMs: use a number for a day of robocalling, discard it, activate a new one.

STIR/SHAKEN cannot distinguish between a legitimate mobile user and a SIM farm. The attestation is technically correct.

### Problem 4: Analytics overcompensate

Because STIR/SHAKEN alone does not block spam, carriers layer analytics engines on top. These systems use call patterns, volume, duration, answer rates, and other signals to flag suspected spam. The problem is that legitimate businesses (particularly those with high outbound call volumes like medical offices, delivery services, and appointment reminders) trigger the same patterns.

The result: "Scam Likely" labels on legitimate calls. Customers who do not answer because their phone flagged the call. Businesses whose [caller reputation](/blog/msp-caller-reputation) is damaged by overzealous spam algorithms. The cure introduces its own disease.

## What businesses can actually do

You cannot fix the framework, but you can protect your outbound caller reputation and manage the reality of inbound spam.

### Protect your outbound reputation

**Verify your attestation level.** Contact your SIP trunk provider and confirm that your outbound calls are signed with A-level attestation. If you are getting B-level because your provider cannot verify your numbers, work with them to register the numbers properly. B-level and C-level calls are more likely to be flagged by analytics engines.

**Register your numbers.** The Free Caller Registry and similar services let you register your business numbers so analytics engines know they are legitimate. This does not guarantee your calls will not be flagged, but it reduces the probability.

**Monitor for spam flags.** Periodically check whether your numbers have been flagged as spam. Call your own numbers from a mobile phone and see if the carrier labels the call. Some paid services provide ongoing monitoring.

**Maintain consistent call patterns.** Sudden spikes in outbound call volume from a number that normally makes 20 calls a day will trigger spam detection. If you are running a legitimate campaign, ramp up gradually and distribute calls across multiple numbers.

**Do not share caller ID across services.** If your main business line is also used for mass outbound calling, the calling pattern can get the number flagged. Use separate DIDs for high-volume outbound and your main business lines.

Use our [carrier lookup tool](/tools/carrier-lookup) to verify the carrier and line type information associated with your numbers. If a number has been ported or shows unexpected carrier information, that can affect attestation.

### Manage inbound spam

**Do not rely solely on carrier spam filtering.** Carrier-level blocking is improving but imperfect. Consider a business phone system with its own call screening capabilities.

**Train users on the gap.** Employees need to understand that caller ID cannot be fully trusted, even with STIR/SHAKEN. A call showing a local number with no spam flag can still be spoofed.

**Report spam calls.** The FCC complaint process and carrier-specific spam reporting tools feed data back into the analytics engines. Reporting improves detection over time.

## Where STIR/SHAKEN goes from here

The framework is not useless; it has made number spoofing harder for domestic callers and has given carriers a data point to feed into their analytics. The FCC continues to tighten requirements, including expanding the mandate to smaller carriers and increasing enforcement for gateway providers that pass through unsigned calls.

But the fundamental limitation remains: STIR/SHAKEN is an identity framework, not a blocking framework. It tells you who the carrier thinks is calling. It does not tell you whether you want to answer. Until caller intent can be verified as reliably as caller identity, the gap between the promise and the reality will persist.

*For the MSP perspective on STIR/SHAKEN compliance, see [STIR/SHAKEN: Why Your Clients' Calls Are Getting Flagged](/blog/msp-stir-shaken). For protecting client caller reputation, see [Keeping Your Clients' Calling Reputation Clean](/blog/msp-caller-reputation).*

---

## AI Voice Agents Are Calling Your SIP Trunk

URL: https://voiptest.com/blog/ai-voice-agents-sip
Published: 2026-05-24
Category: Industry
Tags: ai, voice-agents, sip-trunking, capacity-planning, codecs, automation

AI voice agents went from novelty to production infrastructure fast. Platforms like Retell AI, Bland, Vapi, and Voiceflow are handling real customer calls: appointment scheduling, order status, first-tier support, outbound campaigns. From the network's perspective, these are regular SIP calls. From a capacity planning and quality perspective, they are something entirely different.

If your organization is deploying AI voice agents, or if you are an MSP whose clients are, the SIP trunks and network infrastructure need to account for call patterns that human callers do not generate.

## How AI voice agents connect

The architecture is straightforward. The AI platform runs a speech pipeline: a language model generates text responses, text-to-speech converts them to audio, and the audio is streamed into an RTP session over a SIP call. Inbound calls arrive on your SIP trunks and are routed to the AI platform. Outbound calls originate from the platform through your trunks to the PSTN.

From your SIP provider's perspective, it is a regular call. The INVITE looks normal. The RTP flows normally. The BYE terminates normally. There is no protocol-level difference between an AI agent call and a human call.

The differences are operational.

## Call patterns that break Erlang assumptions

Traditional voice capacity planning uses Erlang formulas. Erlang B tells you how many trunk channels you need given an offered load and an acceptable blocking probability, where offered load is simply arrival rate multiplied by mean holding time (the definitions live in ITU-T E.600). The math itself does not care whether the caller is human or software. What the classic single-number busy-hour treatment assumes is that arrivals are random and roughly stationary, which holds for human callers because their patterns are predictable: they follow business hours, they have natural gaps between calls, they build gradually in the morning and taper off in the evening.

AI agents violate those assumptions, not the underlying math.

**Instant scale-up.** When an outbound campaign launches, an AI agent can attempt to place hundreds of calls simultaneously. There is no gradual ramp. One moment the trunks are idle, the next they are at capacity. Your SIP trunk provider may rate-limit or reject calls if the spike exceeds your contracted channel count or their fraud detection thresholds.

**No breaks.** A human agent handles a call, does post-call work, takes a break, chats with a colleague. An AI agent finishes a call and immediately starts the next one. Trunk utilization per agent is significantly higher than the equivalent human.

**Uniform call duration.** Human calls have variable duration: some are 30 seconds, some are 20 minutes. AI agent calls tend to cluster around a narrower duration range because the conversations follow scripted flows. Erlang B itself is insensitive to the holding-time distribution (only the mean matters), so this alone does not break the model, but combined with correlated launches and retry storms, the real peak can sit far above what a busy-hour average predicts.

**Off-hours traffic.** AI agents can call during hours when your trunk utilization was traditionally zero. If your capacity planning assumed daytime-only traffic, you may need to revisit the numbers.

### How to size it

Do not throw Erlang out; feed it honest inputs, or bypass the averaging entirely. For AI-heavy trunks, measure your actual arrival and holding-time distributions and either model the launch windows separately (a time-varying or simulated model) or size directly against the worst case:

1. **Peak concurrent calls**: what is the maximum number of simultaneous AI calls your system can generate? Include both inbound and outbound.
2. **Headroom**: add 20-30% above peak for human calls sharing the same trunks.
3. **Provider limits**: check your SIP trunk provider's concurrent channel limit and calls-per-second (CPS) limit. CPS limits are often lower than you expect: many providers limit to 1-5 new calls per second per account.

Use the [bandwidth calculator](/tools/bandwidth-calculator) to determine the throughput needed for your peak concurrent call count. Multiply concurrent calls by the per-call bandwidth for your codec (roughly 87 Kbps per direction for G.711 at 20 ms packetization on Ethernet, 30-40 Kbps for Opus; the exact figure shifts with headers and encapsulation).

## The codec question

Codec selection matters more for AI voice than for human voice, because synthesized speech has different acoustic characteristics than natural speech.

**G.711 (PCMU/PCMA)**: uncompressed, 64 Kbps. The safest choice for PSTN termination. No compression artifacts. The audio quality is limited only by the 8 kHz sampling rate, which is the same limitation human callers have on traditional calls. Works everywhere.

**Opus**: adaptive bitrate, wideband or narrowband. Excellent for AI voice because it can encode the full spectrum of synthesized speech and adapt to network conditions in real time. If both sides support Opus (common in browser-based platforms), use it. The quality difference is noticeable: synthesized speech sounds more natural at higher bandwidth.

**G.729**: compressed, 8 Kbps. Saves bandwidth but introduces compression artifacts. On human speech, these artifacts are minor. On synthesized speech, they can be more noticeable because TTS audio has different spectral characteristics than natural voice. The compression can make an AI agent sound more robotic than it should. Avoid G.729 for AI voice if bandwidth permits.

The codec negotiation happens in the [SDP exchange](/blog/sdp-media-negotiation) during call setup. Make sure your SIP trunk provider and your AI platform agree on codec priority. If the provider forces G.729 and your AI platform is optimized for Opus, the quality will suffer.

## Quality monitoring changes

Monitoring AI call quality requires the same metrics as human calls ([jitter](/blog/what-is-jitter-and-why-it-matters), [packet loss](/blog/understanding-voip-packet-loss), [latency](/blog/latency-jitter-packet-loss-details)), but the interpretation is different.

**Latency sensitivity is higher.** In a human-to-human call, 150 ms of one-way latency, the commonly cited ITU-T G.114 planning boundary, is workable because humans naturally pause between conversational turns. AI agents respond faster; many platforms aim for under 500 ms response time including language model inference. Additional network latency stacks on top of that, and the caller perceives the total delay. If your network adds 200 ms of latency and the AI platform adds 400 ms of processing time, the caller waits 600 ms for a response, which feels sluggish.

**Packet loss is less forgiving.** Human callers unconsciously compensate for brief audio gaps: they fill in missed words from context. A caller listening to a synthesized voice does not extend the same benefit. Audio gaps in TTS output sound like glitches, not like a natural conversation artifact. A sensible operating target is packet loss under 0.5% for AI voice, tighter than the roughly 1% often targeted for human calls; both are engineering objectives, not protocol thresholds, and burst loss hurts more than the average suggests.

**Jitter buffer tuning.** Some AI platforms manage their own jitter buffers. If the jitter buffer is too aggressive (large), it adds latency to the already-latency-sensitive AI response. If it is too small, jitter causes audio artifacts. Work with the platform vendor to tune the buffer for your network conditions.

Run our [VoIP quality test](/tools/voip-test) on the network path between your infrastructure and your SIP trunk provider. The results show whether your network can support the tighter quality requirements that AI voice demands.

## Regulatory and caller ID considerations

AI voice agents making outbound calls have the same regulatory obligations as human-dialed calls:

**TCPA compliance.** Automated calls to cell phones require prior express written consent. The FCC does not distinguish between an AI agent and a human agent for consent purposes. If anything, enforcement is stricter for automated systems.

**STIR/SHAKEN attestation.** Calls from AI agents go through the same [STIR/SHAKEN](/blog/msp-stir-shaken) framework. If your AI agent is generating high call volumes, your attestation level and [caller reputation](/blog/msp-caller-reputation) matter even more. A sudden spike in outbound calls from numbers that were previously low-volume can trigger spam flagging.

**Disclosure.** Several states and proposed federal rules require disclosure that the caller is an AI. Check your jurisdiction's requirements.

Use our [carrier lookup](/tools/carrier-lookup) to verify line types before outbound campaigns. Calling mobile numbers without consent carries higher regulatory risk than calling fixed lines.

## Separating AI and human traffic

If your AI call volume is significant, consider separate SIP trunks for AI and human traffic. This gives you:

- **Independent capacity planning.** Scale AI trunks without affecting human callers' access to channels.
- **Separate quality monitoring.** Track AI call quality metrics independently. Problems with AI call patterns do not obscure issues with human calls and vice versa.
- **Different provider configurations.** You may want different codecs, different CPS limits, or different caller IDs for AI traffic.
- **Blast radius containment.** If the AI platform malfunctions and floods the trunks with calls, human callers are not affected.

This is the same principle as putting phones on a [separate VLAN](/blog/office-network-vlans): isolate the traffic so problems in one domain do not spill over into another.

*For SIP trunk fundamentals, see [SIP Trunking: Connecting to the Outside World](/blog/sip-trunking). For capacity planning, see [Capacity Planning and Scaling](/blog/msp-capacity-planning).*

---

## How to Find the Failing Call in a Huge SIP Trace

URL: https://voiptest.com/blog/reading-sip-traces-without-losing-your-mind
Published: 2026-05-24
Category: Guides
Tags: sip, troubleshooting, packet-capture, voip, pcap

You have a packet capture. Someone told you the answer is in there. You open it and there are 4,000 SIP messages, half of which are REGISTER keep-alives, and the other half are OPTIONS pings that have nothing to do with the problem. The call you care about is buried somewhere in the middle.

This is the part where most people give up and call the provider. But you do not have to read every message. You need a strategy for cutting through the noise and getting to the one that matters.

## The problem with raw SIP traces

SIP is text-based, which is both its greatest strength and its most annoying property when troubleshooting. Every message is human-readable. That sounds great until you realize a single call generates seven messages at minimum (INVITE, 100, 180, 200, ACK, and eventually BYE, 200) and usually more once authentication challenges and re-INVITEs are involved, and a busy system produces thousands of messages per hour. Most of them are routine and uninteresting.

The messages you care about are the ones where something went wrong. But they look exactly like the ones where everything went right, except for a different number on the first line.

## Step 1: Kill the noise

Before you look at anything else, filter out the traffic that is definitely not your problem.

**Remove REGISTERs.** Unless you are specifically troubleshooting registration failures, REGISTER messages are just keep-alive noise. Every phone on the system sends them every few minutes. On a 50-phone system, that is hundreds of messages per hour that have nothing to do with call quality or call failures.

In Wireshark:
```
sip && !(sip.Method == REGISTER)
```

**Remove OPTIONS.** Many systems send OPTIONS messages as keep-alive pings between the PBX and the provider. They confirm the trunk is up. Unless the trunk itself is the problem, filter them out:

```
sip && !(sip.Method == REGISTER) && !(sip.Method == OPTIONS)
```

**Remove SUBSCRIBE and NOTIFY.** Presence and BLF (busy lamp field) traffic generates a constant stream of SUBSCRIBE/NOTIFY exchanges. On a system with BLF configured on every phone, this can be the majority of SIP traffic by volume:

```
sip && !(sip.Method == REGISTER) && !(sip.Method == OPTIONS) && !(sip.Method == SUBSCRIBE) && !(sip.Method == NOTIFY)
```

After these filters, you are left with actual call traffic: INVITEs, responses, and BYEs.

## Step 2: Find the call

Now that the noise is gone, find the specific call you are looking for. You usually know at least one of these:

**The phone number.** Filter by the caller or callee:
```
sip.from.user == "2125551234" || sip.to.user == "2125551234"
```

**The time.** If you know approximately when the problem happened, scroll to that timestamp. Wireshark's time display (View > Time Display Format > Time of Day) makes this easier than reading Unix timestamps.

**The error.** If you know the call failed, find the failure:
```
sip.Status-Code >= 400
```

This shows every error response in the trace. From there, look at the To header to find the called number and the Call-ID to isolate the full dialog.

## Step 3: Follow the Call-ID

Every message in a SIP call shares the same Call-ID header. Once you find any message from the call you care about, right-click on the Call-ID field and select "Apply as Filter > Selected." Now you see every message in that dialog, in order, with nothing else cluttering the view.

This is the single most useful trick for reading SIP traces. One filter and you go from thousands of messages to the 8-15 that tell the complete story of one call.

## Step 4: Read the story

With the call isolated, read the messages in order. Every SIP call follows a predictable pattern, and deviations from that pattern are where the problems live.

**Normal successful call:**
1. INVITE (caller to callee)
2. 100 Trying (immediate acknowledgment)
3. 180 Ringing (callee is ringing)
4. 200 OK (callee answered)
5. ACK (caller confirms)
6. [media flows]
7. BYE (one side hangs up)
8. 200 OK (other side acknowledges)

**What to look for:**

**No 100 Trying after the INVITE:** The next hop never received the INVITE, or it crashed before it could respond. Network connectivity issue or the destination is down.

**INVITE retransmissions:** If you see the same INVITE sent multiple times (same Call-ID, same CSeq, same branch), the sender is not getting a response and is retrying per RFC 3261 timers. Something between the two sides is swallowing the packets.

**180 Ringing but no 200 OK:** The callee's phone rang but was never answered. If this is followed by a 480 (Temporarily Unavailable) or 487 (Request Terminated), that is normal. If it times out to a 408, the callee's phone might have crashed or lost connectivity while ringing.

**200 OK with wrong SDP:** If the call connects but audio does not work, look at the SDP body in the 200 OK. Check the `c=` line (connection address) and the `m=` line (media port). If the connection address is a private IP like 10.x.x.x or 192.168.x.x, that is your NAT problem. The remote side cannot send RTP to a private address.

**Call drops about 32 seconds after the 200 OK:** the classic signature of a missing ACK. Per [RFC 3261 as revised by RFC 6026](https://www.rfc-editor.org/rfc/rfc6026.html), the answering side retransmits its 200 OK at intervals starting at T1 (500 ms) and capped at T2, and gives up at 64×T1, roughly 32 seconds, then tears the call down. Look for repeated 200 OKs with no ACK between them; the ACK is usually being lost to NAT or sent to an unroutable Contact address. This is not a session-timer problem: SIP session timers (RFC 4028) have a 90-second minimum interval and deployments commonly use much longer values like 1,800 seconds, so they cannot produce a ~30-second drop. A connection that just stops without any BYE at some other fixed interval points instead at a NAT pinhole or firewall UDP timeout that is too short.

**Re-INVITE mid-call:** A re-INVITE changes the media parameters of an existing call (hold, codec change, call transfer). If a re-INVITE fails, the call may drop or audio may stop. Check the response to the re-INVITE.

## Step 5: Check the SDP

For audio quality issues, the signaling itself may look fine. The problem is in how the media session was negotiated. Look at the SDP bodies in the INVITE and the 200 OK:

```
v=0
o=- 12345 12345 IN IP4 10.0.0.50
c=IN IP4 10.0.0.50
m=audio 18000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
```

The critical fields:
- `c=IN IP4 10.0.0.50` -- where to send media. If this is a private IP, you have a NAT problem.
- `m=audio 18000` -- the RTP port. If this is 0, [the stream has been rejected](https://www.rfc-editor.org/rfc/rfc3264.html).
- `a=rtpmap` lines -- the codecs. Both sides need to agree on at least one.

Compare the SDP in the INVITE with the SDP in the 200 OK. The 200 OK's SDP is the answer. If the caller offered G.711 and Opus but the answer only contains G.729, you know what codec is being used. If there is a codec mismatch or the answer contains no codecs the caller offered, the call will fail or have no audio.

## When you would rather not do any of this

Everything described above works. It is also slow, manual, and requires you to hold the SIP state machine in your head while correlating messages across a potentially large capture.

If you have a pcap file and you want answers without doing the detective work yourself, [SIP Call Stories](/tools/sip-call-stories) reads the same capture file and produces a plain-English story for every call. It identifies the failures, explains what each response code means and what to check next, and flags problems like a registration that keeps failing or a codec negotiation that got rejected. You upload the file, pick a call from the list, and read what happened.

For the full technical breakdown including RTP stream analysis and per-call quality metrics, the [PCAP Analyzer](/tools/pcap-analyzer) extracts every SIP dialog and RTP stream, maps them to each other, and calculates jitter, loss, and MOS scores per stream.

Both tools accept standard pcap and pcapng files, process them in memory, and never store your capture.

---

*This post is about narrowing a large capture down to one call. For the tools themselves (Wireshark and sngrep setup, capture filters, and annotated example traces for a normal call, a NAT failure, and a broken registration), see [Reading a SIP Trace: Practical Troubleshooting](/blog/reading-a-sip-trace) in the [SIP Signaling From the Wire Up](/blog/series/sip-signaling-from-the-wire-up) series.*

---

## One-Way Audio: A Packet-Level Walkthrough

URL: https://voiptest.com/blog/one-way-audio-packet-level
Published: 2026-05-23
Category: Troubleshooting
Tags: one-way-audio, nat, rtp, sip, sdp, packet-capture, voip-troubleshooting

One-way audio is the most frustrating VoIP problem to troubleshoot without a packet capture. The call connects. Both sides see the call as active. One person talks and the other person hears them. But the audio only flows in one direction. Nobody can figure out why, because from the signaling perspective, the call is fine.

The answer is almost always visible in the packets if you know where to look. This walkthrough follows a one-way audio scenario from call setup through media flow, showing exactly what goes wrong and how the packet capture reveals it.

## The setup

Two phones are trying to have a conversation:

- **Phone A** is inside an office behind a NAT router. Its local IP is 192.168.1.50. The office's public IP is 203.0.113.10.
- **Phone B** is at a remote site with a public IP of 198.51.100.20.

Phone A calls Phone B through a SIP provider. The signaling goes through the provider's proxy. The media (RTP audio) is supposed to flow directly between the two phones.

One caveat before we dive in: every address, port, and NAT behavior in this walkthrough is an example. RTP ports come from configuration and the SDP offer/answer exchange (RFC 3264), not from any fixed range, and NAT routers differ by vendor in how they map, time out, and rewrite traffic. The *pattern* is what transfers to your own captures.

## The INVITE: where the problem is planted

Phone A sends an INVITE to Phone B. Inside the INVITE is an SDP body that tells Phone B where to send audio:

```
INVITE sip:5678@provider.example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK776
From: <sip:1234@provider.example.com>;tag=abc123
To: <sip:5678@provider.example.com>
Call-ID: 98765@192.168.1.50
Contact: <sip:1234@192.168.1.50:5060>
Content-Type: application/sdp

v=0
o=- 20001 20001 IN IP4 192.168.1.50
c=IN IP4 192.168.1.50
m=audio 18000 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
```

The critical line is `c=IN IP4 192.168.1.50`. This is Phone A telling Phone B: "send my audio to 192.168.1.50 port 18000." But 192.168.1.50 is a private RFC 1918 address. It only exists inside Phone A's office network. Phone B has no route to it.

This is where the problem starts. The INVITE looks perfectly normal. The call will complete successfully. But the media path is broken from the beginning.

## The 200 OK: the other side responds correctly

Phone B receives the INVITE (routed through the provider) and answers:

```
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK776
From: <sip:1234@provider.example.com>;tag=abc123
To: <sip:5678@provider.example.com>;tag=def456
Call-ID: 98765@192.168.1.50
Contact: <sip:5678@198.51.100.20:5060>
Content-Type: application/sdp

v=0
o=- 30001 30001 IN IP4 198.51.100.20
c=IN IP4 198.51.100.20
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
```

Phone B's SDP says `c=IN IP4 198.51.100.20`. This is a public IP. Phone A can reach it. So far, Phone B has done everything right.

The call is now established. Both sides think the call is active. Here is what happens next.

## The media: one direction works, one does not

**Phone A to Phone B (works):**

Phone A starts sending RTP packets from 192.168.1.50:18000 to 198.51.100.20:20000. These packets hit Phone A's NAT router, which rewrites the source address from 192.168.1.50:18000 to the public address 203.0.113.10:49152 (or whatever ephemeral port the router assigns). Phone B receives audio from 203.0.113.10:49152. The audio plays fine.

In the packet capture on Phone B's side, you see:
```
203.0.113.10:49152 -> 198.51.100.20:20000  RTP PCMU
203.0.113.10:49152 -> 198.51.100.20:20000  RTP PCMU
203.0.113.10:49152 -> 198.51.100.20:20000  RTP PCMU
```

Phone B hears Phone A perfectly.

**Phone B to Phone A (fails):**

Phone B tries to send RTP to the address Phone A advertised in the SDP: 192.168.1.50:18000. Phone B sends packets to 192.168.1.50:18000. These packets go nowhere. 192.168.1.50 is not routable on the public internet. They are either dropped immediately by Phone B's router (because it has no route to a private address) or they get lost somewhere in transit.

In the packet capture on Phone A's side, you see:
```
192.168.1.50:18000 -> 198.51.100.20:20000  RTP PCMU
192.168.1.50:18000 -> 198.51.100.20:20000  RTP PCMU
192.168.1.50:18000 -> 198.51.100.20:20000  RTP PCMU
```

Phone A's outbound audio is being sent. But there are zero inbound RTP packets from Phone B. Phone A hears silence.

This is one-way audio. Phone B hears Phone A. Phone A hears nothing.

## What the packet capture reveals

If you open this capture in Wireshark and go to Telephony > RTP > RTP Streams, you see two streams for this call:

| Source | Destination | Packets | Lost | Jitter |
|--------|------------|---------|------|--------|
| 192.168.1.50:18000 | 198.51.100.20:20000 | 4800 | 0 | 2.1ms |
| 198.51.100.20:20000 | 192.168.1.50:18000 | 0 | - | - |

The first stream (Phone A to Phone B) has 4800 packets, no loss, low jitter. That direction is fine. The second stream (Phone B to Phone A) has zero packets captured at Phone A's end. The audio never arrived.

If you captured on Phone B's side instead, you would see Phone B sending packets to 192.168.1.50:18000 and getting no ICMP unreachable response, no error of any kind. The packets just disappear.

## The fix

The root cause is that Phone A advertised a private IP in its SDP. The fix depends on your setup:

**STUN.** Configure Phone A to use a STUN server. Before placing a call, the phone sends a request to the STUN server, which replies with the phone's public IP and port. The phone then uses this public address in its SDP instead of 192.168.1.50. Phone B sends audio to the public address, the NAT router recognizes the return traffic, and forwards it to Phone A. Whether this works depends on the NAT's behavior: it assumes the router reuses the same public mapping for different destinations, which many NATs do but symmetric NATs do not; that is why ICE (RFC 8445) combines STUN with candidate testing and relay fallbacks.

**SIP provider media proxy.** Many SIP providers run a media proxy that rewrites the SDP to insert the proxy's address. Both sides send audio to the proxy, and the proxy relays it. This solves the NAT problem at the cost of adding a hop (and potentially more latency and jitter). Most hosted PBX providers do this by default.

**Disable SIP ALG.** If your router has SIP ALG enabled, it may be rewriting SDP addresses incorrectly, making the problem worse instead of better. Most VoIP providers recommend turning it off because ALG implementations are so often buggy, but check your provider's and router vendor's guidance, since a few setups depend on a correctly working ALG.

**Symmetric RTP.** Some phones and PBXs support symmetric RTP, which means they send RTP from the same port they expect to receive on. Combined with the NAT router's connection tracking (which creates a pinhole for return traffic on the same port mapping), this can fix one-way audio without STUN. Your phone or PBX may call this "NAT keep-alive" or "comedia" mode.

## Variations on the theme

### Both sides behind NAT

If both Phone A and Phone B are behind NAT routers and both advertise private IPs, you get zero-way audio: neither side can reach the other. The call connects (signaling goes through the provider's proxy) but nobody hears anything.

### Audio works initially then stops

NAT mappings have timeouts, and the values vary widely by router vendor and configuration: anywhere from tens of seconds to many minutes for UDP. If a call is on hold or the conversation goes quiet long enough, the NAT router may expire the UDP pinhole. When audio resumes, the mapping is gone and return packets can no longer reach the internal phone. This looks like one-way audio that started working and then broke mid-call.

### One-way audio only on transfers

Call transfers trigger a re-INVITE that renegotiates the media session. If the new SDP has the same private IP problem, the transferred call will have one-way audio even though the original call was fine. This happens because the original NAT mapping was specific to the original RTP port pair, and the transfer creates a new media session.

## Finding this in your own captures

The pattern is always the same: look at the SDP in the INVITE and the 200 OK. If either side has a private IP (10.x.x.x, 172.16-31.x.x, 192.168.x.x) in the `c=` line, and the other side is on a different network, you have found the problem.

If you have a pcap file and want to skip the manual analysis, the [PCAP Analyzer](/tools/pcap-analyzer) extracts every SIP dialog, identifies the media addresses from the SDP, maps the RTP streams, and flags asymmetric media flow. It shows you which direction has packets and which does not, along with the SDP addresses that explain why.

[SIP Call Stories](/tools/sip-call-stories) approaches the same capture from the signaling side: it tells each call's story in plain English: what happened, how long setup took, which side ended it, and what every failure code means.

Both tools process your capture in memory and never store it. Only the extracted analysis comes back to your browser.

---

## Wireshark for VoIP: A Practical Guide to Capturing and Analyzing SIP/RTP

URL: https://voiptest.com/blog/wireshark-voip-guide
Published: 2026-05-23
Category: Guides
Tags: wireshark, pcap, sip, rtp, troubleshooting, packet-capture

Wireshark is the standard tool for diagnosing VoIP problems. When someone says "the calls sound bad" and you need to know why, a packet capture tells you exactly what happened on the wire. No guessing, no "it might be the network": the packets tell the story.

This guide covers the practical workflow: capturing VoIP traffic, filtering it efficiently, extracting quality metrics, and identifying the most common problems. If you want the theory behind SIP signaling, see [Reading a SIP Trace: Practical Troubleshooting](/blog/reading-a-sip-trace). This post is about using Wireshark effectively.

## Setting up the capture

### Where to capture

Where you place the capture point matters. Capturing on the wrong device gives you incomplete data.

**On the VoIP phone's subnet**: captures everything the phone sends and receives. Best for diagnosing phone-specific issues like registration failures, codec negotiation, and audio problems on a single device.

**On the router/firewall**: captures traffic as it enters and exits the network. Best for diagnosing NAT issues, [SIP ALG problems](/blog/sip-alg-the-setting-that-breaks-everything), and WAN-side quality issues. Many firewalls (pfSense, FortiGate, SonicWall) have built-in packet capture tools that export to pcap format.

**Port mirror / SPAN port**: configure your switch to mirror the VoIP VLAN traffic to a port where your Wireshark machine is connected. This captures all VoIP traffic on the network without affecting performance. Best for capturing multiple calls or intermittent problems.

### Capture filter

Use a capture filter to limit what Wireshark records. VoIP traffic is a mix of SIP signaling (call setup and teardown) and RTP media (the actual audio). Capture both:

```
port 5060 or udp portrange 10000-20000
```

This catches SIP on port 5060 and RTP on a commonly used media port range. Both are conventions, not protocol invariants (the actual transport and ports come from your configuration, DNS records, and the SDP exchange), so check your PBX and provider settings and adjust the filter to match. If you are using TLS-encrypted SIP (port 5061), add `or port 5061`, though you will not be able to read the SIP content without the decryption keys. Browser-based calling is different again: its signaling rides an encrypted WebSocket connection instead of port 5060, which changes what a capture can show you ([SIP and WebSockets](/blog/sip-and-websockets) covers how that path works).

If you are capturing on a busy network and only care about one phone, add the IP:

```
host 192.168.1.100 and (port 5060 or udp portrange 10000-20000)
```

### Start the capture and reproduce the problem

Start the capture, make the call that demonstrates the problem, let it run for the duration of the issue, then stop the capture. Label your capture files clearly: `bad-call-2026-04-03.pcapng` is much more useful than `capture7.pcapng` six months later.

## Finding calls in the capture

### Telephony > VoIP Calls

This is the fastest way to find calls in a capture. Go to **Telephony > VoIP Calls**. Wireshark parses all SIP dialogs and shows each call with its start time, from/to, state, and duration. Select a call and click **Flow Sequence** to see the complete signaling ladder diagram: INVITE, 100 Trying, 180 Ringing, 200 OK, ACK, BYE.

This is the visual equivalent of reading [Your First Call Flow: INVITE to BYE](/blog/first-call-flow-invite-to-bye), but with your actual call data.

### Display filters

If you prefer working with the packet list, these display filters isolate VoIP traffic:

**All SIP traffic:**
```
sip
```

**SIP requests only (no responses):**
```
sip.Request-Line
```

**A specific call by Call-ID:**
```
sip.Call-ID == "abc123@192.168.1.100"
```

**All RTP traffic:**
```
rtp
```

**SIP error responses (4xx, 5xx, 6xx):**
```
sip.Status-Code >= 400
```

**Registration traffic only:**
```
sip.Method == "REGISTER"
```

Find the Call-ID from any SIP message in the call, then filter by that Call-ID to see the complete signaling for a single call without noise from other calls. For a full strategy on stripping out REGISTER, OPTIONS, and presence chatter before you hunt for the problem call, see [Reading a SIP Trace Without Losing Your Mind](/blog/reading-sip-traces-without-losing-your-mind).

## Analyzing SIP signaling

### The INVITE tells you the call setup story

Select the initial INVITE and expand the SIP headers. The critical fields:

**From / To**: who initiated the call and who it was directed to. Check for correct caller ID information.

**Contact**: the address where the phone wants to receive responses. If this contains a private IP address (192.168.x.x, 10.x.x.x) and the call is traversing NAT, this is a problem. The other side will try to send responses to a private IP it cannot reach. This is the classic [SIP ALG](/blog/sip-alg-the-setting-that-breaks-everything) and [NAT traversal](/blog/sip-nat-traversal) failure.

**Via**: the path the request has taken. Each proxy or device that handles the message adds a Via header. The `rport` and `received` parameters show the actual source IP and port as seen by the next hop, which is how NAT is detected.

**SDP body**: the media description. Look at the `c=` line (connection address: where to send RTP) and the `m=` line (media port and codec list). If the `c=` line contains a private IP and this is an external call, media will fail to reach the phone.

### Response codes tell you what went wrong

If the call did not connect, the SIP response code tells you why. See [SIP Response Codes: A Practical Reference](/blog/sip-response-codes) for the full list. The most common failures:

- **401/407**: authentication required / proxy authentication required. Normal in registration flows, problematic if the phone cannot authenticate.
- **403**: forbidden. The provider is rejecting the call. Check credentials, IP whitelisting, or caller ID configuration.
- **404**: not found. The dialed number does not exist at the provider.
- **408**: request timeout. The other side did not respond. Network connectivity issue.
- **486**: busy here. The called party is on another call.
- **488**: not acceptable here. Codec negotiation failed: the two sides cannot agree on a common codec.
- **503**: service unavailable. The provider or server is overloaded or down.

## Analyzing RTP media quality

### Telephony > RTP > RTP Streams

This view shows every RTP stream in the capture. Each phone call typically has two streams, one in each direction. The columns you care about:

**Packets**: total packet count. A 60-second call at 20 ms packetization (50 packets per second) should show approximately 3,000 packets per stream; at 30 or 60 ms packetization the expected count drops accordingly. Significantly fewer packets in one direction versus the other indicates one-way audio.

**Lost**: packets that never arrived, detected by gaps in the RTP sequence numbers. Under 1% is a common operating target; over 3% the call quality is usually noticeably degraded, though the audible effect depends on the codec, its concealment (PLC/FEC), and whether the loss is random or bursty.

**Max Delta**: the longest gap between consecutive packets. The healthy baseline is your packetization interval: around 20 ms for a 20 ms stream, 30 ms for a 30 ms stream, and so on. Spikes far above the interval (say 100 ms on a 20 ms stream) indicate jitter events that will be audible.

**Max Jitter**: the interarrival jitter estimate computed per RFC 3550 (a statistical smoothed value, not a worst-case delay). Under 30 ms is a common operating target, not a universal pass/fail line; what matters is whether the playout buffer can absorb it.

**Mean Jitter**: the average jitter. If this is low but max jitter is high, you have occasional spikes rather than consistently bad quality.

Select a stream and click **Analyze** for a detailed per-packet view including a jitter graph. The graph is invaluable: it shows you exactly when quality degraded during the call, which helps correlate with other network events.

### Diagnosing one-way audio

Go to RTP Streams. Find the two streams for the problematic call (they will have the same IP pair but reversed source/destination). If one stream has packets and the other has zero or very few:

1. Check the SDP `c=` line in the INVITE and 200 OK. Is either side advertising a private IP address? If yes, the media is being sent to an unreachable address.
2. Check if SIP ALG rewrote the SDP. Compare the INVITE as sent by the phone (capture on the LAN) with the INVITE as seen on the WAN. If the `c=` address or `m=` port changed, ALG is mangling the media description.
3. Check your firewall rules. RTP uses high UDP ports: 10000-20000 is a common default, but the actual range is whatever your PBX or phones are configured to use and advertise in SDP. If the firewall is blocking inbound UDP on those ports, return audio cannot reach the phone.

### Diagnosing choppy audio

Both streams have packets, but the call sounds choppy or robotic:

1. Check the jitter graph. Consistent high jitter across the call points to a network quality issue: congestion, [bufferbloat](/blog/bandwidth-doesnt-mean-quality), or a bad network segment.
2. Check for periodic jitter spikes. Spikes every few seconds that align with other traffic patterns suggest bandwidth contention. Another device on the network may be sending bursts of data that crowd out the VoIP packets.
3. Check packet loss. Even 1-2% loss is audible. If loss is concentrated in bursts rather than evenly distributed, the audio will sound like brief dropouts rather than consistent degradation.

## Skipping the manual work

Wireshark is powerful but time-consuming. If you need answers quickly, or if someone on your team does not know Wireshark, upload the capture file to our [PCAP analyzer](/tools/pcap-analyzer). It automatically extracts RTP streams, maps SIP dialogs, and calculates per-stream quality metrics. You get the same information as the Wireshark analysis above, presented in a structured report without manual filtering.

This is particularly useful when a customer or remote technician captures traffic and emails you a pcap file. Instead of walking them through Wireshark, send them to the analyzer and review the results together.

*For the SIP signaling theory behind what you see in these captures, see [Reading a SIP Trace: Practical Troubleshooting](/blog/reading-a-sip-trace). For common SIP problems and their packet-level signatures, see [Common SIP Problems and What They Look Like](/blog/common-sip-problems).*

---

## 500 Mbps and Your Calls Still Sound Terrible

URL: https://voiptest.com/blog/bandwidth-doesnt-mean-quality
Published: 2026-05-22
Category: Troubleshooting
Tags: voip-quality, bandwidth, bufferbloat, jitter, latency, speed-test

"We have 500 Mbps fiber. The calls still sound terrible." This is one of the most common complaints in VoIP, and it reveals a fundamental misunderstanding about what makes voice calls work.

Speed tests measure throughput: how many megabits per second your connection can push. VoIP does not need throughput. A single G.711 call at 20 ms packetization uses roughly 87 Kbps per direction on Ethernet (the exact figure shifts with headers and encapsulation). Your 500 Mbps connection has thousands of times more bandwidth than one call needs. Even with 50 simultaneous calls, you would be using less than 1% of your available bandwidth.

The problem is not how fast your connection is. The problem is how consistent it is.

## What VoIP actually needs

Voice is a real-time application. Audio packets need to arrive at the other end in order, on time, and without gaps. The codec at the receiving end reconstructs audio from these packets in real time. If a packet arrives late, it is useless; the codec has already moved on. If a packet is lost, there is a gap in the audio. If packets arrive with inconsistent timing, the audio sounds choppy or robotic.

This is fundamentally different from downloading a file or loading a web page. Those applications are tolerant of variable delivery: your browser does not care if a chunk of data arrives 200 milliseconds later than the previous chunk. It just waits and assembles the result. VoIP cannot wait. The conversation is happening now.

The metrics that determine VoIP quality are:

**[Jitter](/blog/what-is-jitter-and-why-it-matters)**: the variation in packet arrival times. If packets normally arrive every 20 milliseconds but occasionally arrive at 5 ms or 80 ms intervals, that variation is jitter. High jitter forces the receiving device to buffer more aggressively, adding delay, or it causes audio gaps when packets arrive too late for the jitter buffer.

**[Packet loss](/blog/understanding-voip-packet-loss)**: the percentage of packets that never arrive. Even 1% packet loss can be audible as clicks, gaps, or choppy audio; how audible depends on the codec's concealment and whether the loss comes in bursts. At 3-5%, calls typically become difficult to follow. VoIP uses UDP, which does not retransmit lost packets.

**[Latency](/blog/latency-jitter-packet-loss-details)**: the one-way delay from sender to receiver. Around 150 ms one-way is the commonly cited ITU-T G.114 transmission-planning boundary, not a cliff where audio fails. As total mouth-to-ear delay climbs past that, conversations become progressively more awkward: people start talking over each other because they do not hear the other person quickly enough.

**A throughput number tells you none of this.** Some modern speed tests do report loaded latency, which helps, but none of them exercise your connection the way a real voice stream does.

## The bufferbloat problem

Bufferbloat is the single most common cause of "fast internet, bad calls" and the least understood.

Your router and modem have buffers: memory that temporarily holds packets when the outbound link is congested. In theory, a small buffer smooths out momentary traffic bursts. In practice, manufacturers ship equipment with enormous buffers because bigger buffers prevent packet loss on speed tests, which makes the product look good in reviews.

Here is what happens: your connection is running near capacity: someone is uploading a video, a cloud backup is running, a large file transfer is in progress. Packets start filling the buffer. Instead of signaling congestion (by dropping packets, which TCP would respond to by slowing down), the oversized buffer absorbs everything. Packets sit in the buffer for 200, 500, sometimes 1,000+ milliseconds before being transmitted.

Your VoIP packets are in that buffer too. They arrive at the other end hundreds of milliseconds late. The jitter buffer on the receiving phone cannot compensate for that much delay. The result: choppy audio, long pauses, talking over each other. The speed test still shows 500 Mbps, because throughput is the headline number it reports; the latency spike is invisible unless the tool measures under load.

### How to detect bufferbloat

Run a speed test and watch the latency during the test, not just the final throughput number. Most speed test tools now show "loaded" vs. "unloaded" latency. If your unloaded latency is 10 ms but your loaded latency (during the download or upload test) jumps to 200+ ms, you have bufferbloat.

Better yet, skip the speed test entirely and run a [VoIP quality test](/tools/voip-test) that measures what actually matters: jitter, packet loss, and latency under conditions that simulate real voice traffic.

### How to fix bufferbloat

**[QoS on your router.](/blog/quality-of-service-explained)** Proper QoS configuration prioritizes voice traffic over bulk data. Even when the connection is saturated, VoIP packets get through without waiting in the buffer. See [QoS: Telling Your Network What Traffic Matters Most](/blog/office-network-qos) for the setup.

**SQM (Smart Queue Management).** Modern router firmware (OpenWrt, Ubiquiti, pfSense) supports SQM algorithms like fq_codel or CAKE that actively manage buffer sizes. SQM limits the buffer depth, which caps the worst-case latency at the cost of slightly lower peak throughput. For VoIP, this is an excellent tradeoff.

**Limit the bandwidth hogs.** Schedule cloud backups, large uploads, and software updates for off-hours. If your connection is never saturated, the buffer never fills, and bufferbloat never manifests. This is a workaround, not a fix, but it buys time while you implement proper QoS.

## The 10 Mbps connection that sounds better

It is entirely possible, and common, for a 10 Mbps connection with 5 ms jitter and 0.1% packet loss to produce crystal-clear calls while a 1 Gbps connection with 80 ms jitter and 2% packet loss sounds terrible.

This is why [dedicated internet access](/blog/dedicated-internet-access) often sounds better than a faster cable connection. DIA provides symmetrical bandwidth with low latency and an SLA for jitter and packet loss. The speed number is lower, but the quality metrics are better. For voice, quality beats quantity every time.

It is also why the [afternoon call quality problem](/blog/afternoon-call-quality) is so common. The connection has plenty of bandwidth at 8 AM when only a few people are online. By 2 PM, with the full team working, the shared cable node is congested, buffers are filling, and jitter spikes. The speed test at 2 PM might still show 400 Mbps, but the latency and jitter tell a different story.

## How to test what actually matters

Stop reaching for a speed test first when diagnosing VoIP problems. Unless it measures latency under load, it answers the wrong question, and even then it says nothing about loss or jitter on a voice-like stream.

Run a [VoIP quality test](/tools/voip-test) instead. It measures jitter, packet loss, latency, and [MOS score](/blog/understanding-mos-scores), the metrics that determine whether your calls will sound good. The results will tell you whether your connection is suitable for voice, regardless of how many megabits per second it can push.

Use the [bandwidth calculator](/tools/bandwidth-calculator) to determine how much throughput your call volume actually needs. You will likely find that bandwidth is not your bottleneck. The bottleneck is consistency, and that requires different tools to measure and different solutions to fix.

*For a detailed explanation of the metrics that matter, see [Latency, Jitter, and Packet Loss: The Details](/blog/latency-jitter-packet-loss-details). For the connection types that deliver the best VoIP quality, start with [Your ISP Is the Foundation Everything Else Sits On](/blog/isp-foundation).*

---

## How to Capture VoIP Traffic With Wireshark (and What to Do With It)

URL: https://voiptest.com/blog/capture-voip-traffic-wireshark
Published: 2026-05-22
Category: Guides
Tags: wireshark, packet-capture, sip, rtp, voip-troubleshooting, pcap

Most VoIP troubleshooting eventually leads to the same place: you need to see what is actually happening on the wire. The phone says it is registered. The provider says the trunk is up. The call still fails, or the audio sounds terrible, or calls drop after about 32 seconds (a classic sign of a missing ACK, but confirming that requires packet evidence). The only way to know what is really going on is to look at the packets.

Wireshark is the tool for this. It is free, it runs on every major operating system, and it has built-in features specifically designed for VoIP analysis. This guide covers how to capture VoIP traffic, how to filter it down to what matters, and what to do with the capture once you have it.

## Before you capture: where to tap

Where you place the capture determines what you can see. This matters more than any filter or setting.

**On the phone itself:** If you are troubleshooting a single phone, some IP phones have built-in packet capture features (Polycom and Yealink both support this). The advantage is that you see exactly what the phone sees. The disadvantage is that phone-side captures are often limited in size and duration.

**On a mirror port:** The best general-purpose approach. Configure a <a href="https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-12/configuration_guide/nmgmt/b_1712_nmgmt_9300_cg/configuring_span_and_rspan.html" rel="nofollow noopener noreferrer" target="_blank">SPAN or mirror port</a> on your managed switch to copy all traffic from the phone's port (or the uplink to the internet) to a monitoring port where your capture machine is connected. This lets you see all traffic without affecting the phones.

**On the PBX:** If you are running a software PBX like Asterisk or FreeSWITCH, you can capture directly on the PBX server. This shows you both sides of every call (the leg between the phone and the PBX, and the leg between the PBX and the provider). tcpdump is usually the fastest option here:

```
tcpdump -i eth0 -w /tmp/capture.pcap port 5060 or portrange 10000-20000
```

This captures SIP signaling on port 5060 and RTP media on a commonly used RTP port range; both are examples, not protocol requirements (RFC 3261 does not force SIP onto 5060; that is just the registered default). Adjust the ports to match your PBX configuration, and remember that SIP over TLS (commonly 5061), SIP over WebSocket (RFC 7118), or media inside a VPN tunnel will not match these filters at all.

**On the WAN interface:** If you suspect the problem is between your network and the provider, capture on the router or firewall's WAN interface. Some firewalls (pfSense, OPNsense, FortiGate) have built-in packet capture. This is especially useful for diagnosing NAT traversal and firewall issues.

## Starting the capture in Wireshark

Open Wireshark, select the correct network interface, and start capturing. If you know you only need VoIP traffic, set a capture filter before you start. Capture filters are applied at the wire level and keep your file small:

```
udp port 5060 or udp portrange 10000-20000
```

This captures SIP signaling and RTP media for a typical deployment; treat it as a starting example. Nondefault SIP ports, SIP over TLS or WebSocket (WSS, [RFC 7118](https://www.rfc-editor.org/rfc/rfc7118.html)), and media tunneled through a VPN will silently fail to match it. If you are unsure of the ports and transports in play, skip the capture filter and capture everything. You can filter later using display filters. The file will be larger, but you will not miss anything.

Let the capture run while you reproduce the problem. If the issue is intermittent, you may need to let it run for a while. For large captures, consider rotating files:

```
tcpdump -i eth0 -w /tmp/voip-%H%M.pcap -G 300 port 5060 or portrange 10000-20000
```

This creates <a href="https://www.tcpdump.org/manpages/tcpdump.1.html" rel="nofollow noopener noreferrer" target="_blank">a new file every 5 minutes</a>, which makes it easier to find the window when the problem occurred.

## Filtering the capture

Once you have a capture, open it in Wireshark and apply display filters to isolate VoIP traffic.

### See all SIP traffic

```
sip
```

This shows every SIP message in the capture: INVITEs, 200 OKs, BYEs, REGISTERs, and everything else. On a busy system that is thousands of messages, most of them routine keep-alives. [Reading a SIP Trace Without Losing Your Mind](/blog/reading-sip-traces-without-losing-your-mind) covers how to cut through the noise and isolate the call you actually care about.

### See SIP and RTP together

```
sip || rtp
```

This shows both signaling and media streams. Useful when you need to correlate call setup with audio delivery.

### Filter to a specific call

Every SIP call has a unique Call-ID header. Once you find the call you are interested in, filter by it:

```
sip.Call-ID == "abc123"
```

Most real Call-IDs are a random token followed by an at sign and the sender's host, like `abc123` plus `@10.0.0.50`. Paste whichever form your trace shows, in full, between the quotes.

### Filter to a specific phone

If you know the phone's IP address:

```
ip.addr == 10.0.0.50 && (sip || rtp)
```

### Find failed calls

```
sip.Status-Code >= 400
```

This shows all SIP error responses: 4xx client errors, 5xx server errors, and 6xx global failures.

## Using Wireshark's VoIP features

Wireshark has two built-in features specifically for VoIP analysis.

### VoIP Calls window

Go to **Telephony > VoIP Calls**. This shows a list of every call in the capture with the caller, callee, start time, duration, and status. You can select a call and click "Flow Sequence" to see a ladder diagram of every SIP message in the call, which side sent it, and the timing between messages.

This is the fastest way to find a specific call and understand the signaling flow. Failed calls show up with their error codes. Calls that set up but never got a BYE might indicate a timeout or network partition.

### RTP Streams window

Go to **Telephony > RTP > RTP Streams**. This shows every RTP stream in the capture with the source and destination, codec, packet count, lost packets, jitter, and duration. Select a stream and click "Analyze" to see per-packet timing, sequence gaps, and jitter graphs.

This is where you find audio quality problems. High jitter, packet loss, or sequence gaps in the RTP stream directly explain choppy audio, robotic voices, and gaps in conversation.

## What to look for

### Call setup failures

Open the VoIP Calls window and look for calls with error status codes. The most common:

- **403 Forbidden:** Authentication failure. Check credentials.
- **404 Not Found:** The dialed number does not exist on the far end.
- **408 Request Timeout:** No response from the remote side. Network connectivity issue.
- **480 Temporarily Unavailable:** The destination is not answering. Could be a phone that is offline.
- **486 Busy Here:** Normal busy signal.
- **503 Service Unavailable:** The provider or PBX is overloaded or down.

Our [SIP Response Code reference](/tools/sip-codes) has plain-English explanations and troubleshooting steps for every code.

### One-way audio

If calls connect but audio only works in one direction, look at the RTP streams. You should see two streams per call (one in each direction). If you only see one, the other direction is being blocked by a firewall or NAT issue. Check the SDP in the INVITE and 200 OK to see what IP addresses and ports each side is advertising for media.

### Audio quality problems

In the RTP Streams window, look at the lost packets and max jitter columns. Common operating targets are less than 1% packet loss and jitter under 30 ms, practical goals rather than protocol thresholds, since the audible impact depends on the codec and playout buffering. If you see high numbers, the issue is in the network between the two endpoints, not in the phones or the PBX.

## Skip the manual analysis

Reading through SIP headers and correlating RTP streams by hand is valuable for learning, but it is slow when you are in the middle of an active outage and a customer is waiting.

Our [PCAP Analyzer](/tools/pcap-analyzer) does this automatically. Upload your pcap file and get structured results: every call identified, every RTP stream analyzed, quality metrics calculated, and common problems flagged. Analysis runs as a background job on our servers, and your capture is removed from the processing queue automatically once the job clears; see the [privacy policy](/privacy) for specifics.

For an even faster read on what went wrong, [SIP Call Stories](/tools/sip-call-stories) generates plain-English diagnostic narratives for every call in the capture. Instead of reading SIP headers, you get a story: "Call from 2125551234 to 2125555678 failed with 408 Request Timeout after 32 seconds. The INVITE was sent but no provisional response was received, suggesting the remote endpoint is unreachable or the request was lost in transit."

Both tools accept standard pcap and pcapng files from Wireshark, tcpdump, or any other capture utility.

---

## SIP ALG: The Router Setting That Breaks Everything

URL: https://voiptest.com/blog/sip-alg-the-setting-that-breaks-everything
Published: 2026-05-21
Category: Technical
Tags: sip-alg, nat, router, troubleshooting, firewall, voip-problems, network

If you are troubleshooting VoIP problems and you have not checked whether SIP ALG is enabled on your router, check now. It is the single most common router-level cause of VoIP failures, and it is enabled by default on a surprising number of routers.

SIP ALG is a feature that is supposed to help VoIP work through NAT. In practice, it causes [one-way audio](/blog/one-way-audio), registration failures, [dropped calls](/blog/calls-dropping-after-set-time), and a catalog of intermittent issues that are maddening to diagnose because they look like they should be impossible.

## What SIP ALG does

To understand why SIP ALG exists, you need to understand the problem it tries to solve.

SIP messages contain IP addresses and port numbers in their headers and bodies. The Contact header includes the phone's IP address. The Via header includes the phone's IP address. The [SDP body](/blog/sdp-media-negotiation) includes the IP address and port where the phone expects to receive audio. These addresses are embedded in the [text of the SIP message](/blog/anatomy-of-a-sip-message) itself.

When a phone sits behind a NAT router, its local IP address (something like 192.168.1.50) is not reachable from the internet. The router translates the source IP of outgoing packets to its public IP address. This works fine for the IP packet header: NAT rewrites it automatically. But the SIP message body still contains the phone's private IP address because NAT operates at the network layer and does not normally look inside application-layer payloads.

The result is that the remote SIP server receives a message where the IP packet came from the router's public IP, but the SIP headers and SDP body say the phone is at 192.168.1.50. The server tries to send audio to 192.168.1.50, which is not routable on the internet. [One-way audio](/blog/one-way-audio): you can hear the other person, but they cannot hear you.

SIP ALG attempts to fix this by inspecting SIP messages as they pass through the router, finding the embedded private IP addresses, and rewriting them to the router's public IP address. In theory, this means the remote server receives consistent addressing information and can route audio correctly.

In theory.

## Why it goes wrong

The concept is sound. The implementations are not. SIP ALG has been poorly implemented across decades of router firmware from dozens of manufacturers, and the result is a feature that creates problems far more often than it solves them.

### It rewrites things it should not

SIP ALG implementations vary in what they rewrite and how. Some rewrite only the Contact and Via headers. Some also rewrite the SDP body. Some rewrite the From and To headers. Some rewrite addresses inside the SIP message that are not IP addresses at all. Some rewrite the message even when the addresses are already correct (because the phone is using STUN or an outbound proxy to handle NAT).

When SIP ALG rewrites a field that the phone or server does not expect to be rewritten, the result is a message that does not match what the sender intended. [SIP authentication](/blog/sip-authentication-security) is particularly vulnerable because authentication digests are computed over specific header values. If the ALG rewrites a header after the phone computed the digest, the authentication fails. The server sees a valid-looking REGISTER or INVITE with an authentication response that does not match, and rejects it.

### It corrupts the Content-Length

SIP messages contain a Content-Length header that specifies the size of the SDP body in bytes. When SIP ALG rewrites IP addresses in the SDP body, the body's byte length changes (a private address like 192.168.1.50 is a different length than a public address like 203.0.113.25). Well-implemented ALGs update the Content-Length to match. Poorly implemented ones do not.

A mismatched Content-Length causes the receiving SIP parser to either truncate the SDP (reading too few bytes) or read past the end of the SDP into the next message (reading too many bytes). Both result in malformed messages that cause call setup failures, [codec negotiation errors](/blog/sdp-media-negotiation), or outright crashes in some SIP stacks.

### It cannot help with encrypted SIP

SIP over TLS (SIPS, RFC 3261) encrypts the SIP signaling. A transparent ALG cannot read the messages, so it cannot rewrite the addresses inside them; the only way a middlebox can modify encrypted SIP is by terminating and re-originating the TLS session itself (as some SBCs legitimately do). What a transparent ALG *can* do to TLS traffic is break it: any blind modification of the ciphertext fails the TLS integrity check and kills the connection, and some routers simply drop or mishandle SIP-over-TLS traffic they cannot inspect. Either way, moving to TLS takes the ALG out of the rewriting business, which is one reason encrypted SIP sidesteps a whole class of ALG bugs.

### It interferes with NAT keepalives

Modern VoIP phones send periodic keepalive packets to maintain their NAT binding: the mapping between the phone's private address:port and the router's public address:port. These keepalives ensure that return traffic (like inbound calls) can reach the phone through NAT.

SIP ALG can interfere with this process by creating its own NAT mappings for SIP traffic that conflict with the phone's keepalive-maintained mappings. The result is that the phone thinks its NAT binding is at one address:port, the remote server thinks it is at another, and inbound calls fail. [Phones stop ringing](/blog/phones-not-ringing) for calls that were routed correctly by the server but could not reach the phone through the confused NAT state.

### It creates asymmetric behavior

Because SIP ALG only operates on the router where it is enabled, its effects are asymmetric. Outbound calls may work fine (the ALG rewrites the outbound SIP message, the remote server gets corrected addressing) while inbound calls fail (the ALG does not correctly handle the inbound INVITE, or its NAT mappings do not match what the server expects). Or calls work in one direction but produce [one-way audio](/blog/one-way-audio) because the SDP was rewritten correctly for one media direction but not the other.

This asymmetry makes troubleshooting confusing. The VoIP system appears to work partially, with failures that are directional, intermittent, or depend on which party initiates the call. These are classic SIP ALG symptoms.

## The symptoms

If SIP ALG is causing problems, you will typically see one or more of these:

**One-way audio.** You can hear the other party but they cannot hear you, or vice versa. The SDP was rewritten incorrectly, causing audio to be sent to the wrong address. This is the most common SIP ALG symptom.

**Registration failures.** Phones cannot register or lose registration frequently. The ALG is corrupting the REGISTER message, causing authentication failure or misdirecting the server's response.

**Calls dropping after about 32 seconds.** The call connects but drops after a consistent short interval. A drop at roughly 32 seconds classically means the ACK to the 200 OK never arrived (the ALG mangled or misrouted it), so the answering side's retransmissions time out (RFC 3261's timer math lands at 64×T1 = 32 seconds) and it tears the call down. Confirming that requires a packet capture; other fixed intervals point at different timers or the router's connection tracking expiring the media flow.

**Inability to receive inbound calls.** Outbound calls work fine. Inbound calls do not ring, ring the wrong extension, or fail with [SIP errors](/blog/common-sip-problems). The ALG's NAT mapping for inbound traffic is incorrect.

**Intermittent failures.** Calls sometimes work and sometimes do not, with no apparent pattern. The ALG's behavior depends on the specific content of each SIP message, the timing of NAT binding refreshes, and possibly the phase of the moon. Inconsistency is the hallmark of a buggy ALG.

## How to check and disable it

### Consumer and small-business routers

**Netgear.** Look under Advanced → WAN Setup → "Disable SIP ALG" or under Advanced → Setup → WAN Setup. Netgear labels it differently across models.

**Linksys.** Some models have SIP ALG under Security → Firewall or Administration → Management. Some models have no option to disable it and require firmware that does not include it.

**TP-Link.** Check Advanced → NAT Forwarding → ALG. SIP ALG is typically a checkbox.

**ASUS.** Look under WAN → NAT Passthrough → SIP Passthrough. Set to "Disable."

**ISP-provided routers/modems.** Many ISP-provided devices have SIP ALG enabled with no option to disable it. If your ISP router does not expose SIP ALG settings, put it in bridge mode and use your own [router](/blog/office-network-router) where you can control the settings.

### Enterprise firewalls

**SonicWall.** Under VoIP → Settings, disable "Enable Consistent NAT" and "Enable SIP Transformations."

**Fortinet/FortiGate.** SIP ALG is part of the application-level gateway under the SIP session helper or SIP ALG profile. It can be disabled per policy or globally.

**pfSense/OPNsense.** Under System → Advanced → Firewall & NAT, uncheck "Disable Firewall Scrub" and under Firewall → NAT, check for SIP proxy or siproxd packages that may be installed.

**Ubiquiti.** EdgeRouter and UniFi Security Gateway have SIP ALG modules that can be disabled via CLI: `set system conntrack modules sip disable`.

After disabling SIP ALG, reboot the router and restart your phones. Existing NAT bindings created by the ALG need to be cleared.

## What to use instead

Modern VoIP handles [NAT traversal](/blog/sip-nat-traversal) without SIP ALG using several mechanisms:

**STUN (Session Traversal Utilities for NAT).** The phone queries a STUN server to discover its public IP address and the NAT mapping for its SIP and RTP ports. It then includes the correct public address in its SIP messages. No router intervention needed.

**Outbound proxy.** The phone sends all SIP traffic through the provider's outbound proxy, which handles NAT traversal on the server side. The phone's private address in the SIP message is expected and handled by the proxy.

**Symmetric RTP.** The phone sends RTP from the same port it expects to receive RTP on, and the remote end sends RTP back to whatever address:port the packets came from rather than what the SDP says. This works through NAT without any ALG because the return path follows the NAT mapping created by the outbound packets.

**SIP keepalives.** The phone sends periodic OPTIONS or empty SIP packets to maintain the NAT binding. As long as the binding stays active, inbound traffic reaches the phone.

These mechanisms are standard in every modern VoIP phone, softphone, and PBX. They were designed specifically because SIP ALG proved unreliable. When you disable SIP ALG, you are not removing a necessary feature; you are removing an obstacle that prevents these proper NAT traversal mechanisms from working correctly.

Most VoIP providers' support teams recommend turning SIP ALG off, and for consumer and small-business routers that advice is usually right, but check your own provider's and firewall vendor's guidance first, because a minority of deployments (typically enterprise firewalls with well-maintained SIP awareness, or legacy endpoints with no NAT traversal of their own) are configured to depend on it. If you are experiencing any of the symptoms described in this post and your provider does not say otherwise, disable it and test. Running a [VoIP quality test](/tools/voip-test) before and after disabling SIP ALG gives you objective data on whether it was affecting your calls, and a [PCAP analyzer](/tools/pcap-analyzer) can reveal exactly how the ALG was rewriting your SIP messages. If the problems resolve, leave it off. If they do not, you have at least eliminated one variable and can move on to other potential causes.

---

## How T.38 Fax Actually Works

URL: https://voiptest.com/blog/how-t38-fax-works
Published: 2026-05-20
Category: Technical
Tags: t38, fax, fax-over-ip, sip, voip-fundamentals, troubleshooting

Fax over VoIP is one of those problems that the industry has been solving for twenty years and still has not fully solved. The basic issue is that fax machines were designed to communicate over dedicated analog circuits with predictable timing, and VoIP provides none of those guarantees. T.38 is the protocol designed to bridge that gap, and understanding how it works explains both why it helps and why it still breaks.

If you are dealing with [fax problems on your VoIP system](/blog/fax-over-ip), this is the protocol-level context behind those issues. If you are still running [analog fax lines](/blog/analog-holdouts) and wondering whether to convert them, this explains what you are converting to.

## Why fax hates VoIP

A fax machine communicates by generating precise analog tones that encode data using modem modulation schemes (V.17, V.29, V.27ter). The receiving fax machine demodulates these tones to recover the data. The process is sensitive to timing in ways that voice is not.

A voice call can typically tolerate jitter on the order of 20ms and around 1% packet loss with minimal perceptible impact; those are common operating targets, and the exact tolerance depends on the codec and jitter buffer in use. The [human brain fills in gaps](/blog/why-voice-is-hard) and compensates for small impairments. A fax modem cannot. The modem's demodulator expects tones to arrive with specific timing relationships. Jitter disrupts those relationships. Packet loss removes chunks of the modulated signal. And audio codecs, especially compressed codecs like G.729, alter the signal in ways that the demodulator cannot recover from.

Sending fax tones through a G.729 codec is like photocopying a photograph, then photocopying the photocopy. The compression algorithm is optimized for human speech, not modem tones. It strips out the signal characteristics the fax modem relies on. The fax fails, sometimes immediately, sometimes partway through a page.

Even G.711 (uncompressed) passes fax tones imperfectly over VoIP because jitter buffers, echo cancelers, and silence suppression all interfere with the precise timing the modem expects.

## Fax passthrough: the brute-force approach

The simplest approach to fax over VoIP is passthrough. The VoIP system detects a fax tone (typically the CNG tone, [the 1100 Hz tone ITU-T T.30 defines for the calling fax machine](https://www.itu.int/rec/T-REC-T.30-200509-I/en)), switches the call to G.711 if it is not already using it, disables echo cancellation, disables silence suppression, switches the jitter buffer from adaptive to a fixed, minimized setting (the buffer still exists; it just stops resizing mid-transmission), and passes the modem audio through the VoIP channel as-is.

Passthrough works when the network is clean. If jitter is low, packet loss is near zero, and no device in the path is modifying the audio, the fax tones arrive intact and the receiving machine demodulates them successfully. On a LAN or a high-quality dedicated connection, passthrough is often reliable enough.

On a typical internet connection with variable jitter and occasional packet loss, passthrough becomes unreliable. A single lost packet during page transmission can corrupt the data. Jitter that exceeds the modem's tolerance causes demodulation errors. The fax machine retries, slows down its transmission speed, or drops the session entirely.

## T.38: demodulate, transmit data, remodulate

T.38 (ITU-T Recommendation T.38) takes a fundamentally different approach. Instead of sending fax tones as audio through the VoIP channel, T.38 demodulates the fax tones at the sending end, transmits the extracted fax data as structured [packets](/blog/how-data-moves-in-packets), and remodulates the tones at the receiving end.

The process works like this:

**Step 1: Fax detection.** The call starts as a normal voice call. When a fax tone is detected (CNG from the sender or CED from the receiver), the gateway initiates a switch to T.38 mode.

**Step 2: SIP re-INVITE.** The gateway sends a [SIP re-INVITE](/blog/sdp-media-negotiation) with an SDP body that specifies T.38 as the media type instead of audio. The SDP includes T.38-specific parameters: supported fax data rate, error correction mode, and transport protocol. If the remote end supports T.38, it accepts the re-INVITE. If not, the re-INVITE is rejected and the call either falls back to passthrough or the fax fails.

**Step 3: IFP packetization.** Once both sides agree on T.38, the sending gateway demodulates the incoming fax tones and encodes the data into IFP (Internet Facsimile Protocol) packets. These packets contain the fax data in a structured format (T.30 signaling messages, page data, and control information) rather than raw audio.

**Step 4: UDPTL transport.** IFP packets are transported using UDPTL (UDP Transport Layer for T.38). That is the transport used in practice rather than RTP, although the T.38 recommendation also defines TCP and RTP transport options. UDPTL is a transport protocol designed specifically for T.38 that includes built-in redundancy. [UDPTL carries redundant copies of prior packets](https://www.itu.int/rec/T-REC-T.38-201511-I/en): each UDPTL packet typically contains the current IFP data plus copies of one or more previous IFP packets. If a packet is lost, the redundant data in subsequent packets allows recovery.

**Step 5: Remodulation.** The receiving gateway takes the IFP data, converts it back to the appropriate fax modem tones, and sends those tones to the receiving fax machine over whatever local connection it has (analog line, ATA, etc.). The receiving fax machine sees what appears to be a normal fax transmission from another fax machine.

The key insight is that the network path between the two gateways carries structured data, not audio. A lost packet does not create a gap in a modem tone; it loses a data packet that can potentially be recovered from redundancy. Jitter does not disrupt modem timing because the remodulation happens locally at the receiving end with its own timing.

## The re-INVITE: where T.38 breaks most often

The transition from voice/audio mode to T.38 mode requires a [SIP re-INVITE](/blog/first-call-flow-invite-to-bye) that both sides must support and accept. This is the most common point of failure.

**The remote end does not support T.38.** Not all [SIP trunking providers](/blog/sip-trunking) support T.38 on all trunks. If the far end rejects the re-INVITE with a 488 Not Acceptable Here or simply does not understand the T.38 SDP, the switchover fails. What happens next depends on the sending gateway's configuration: it may fall back to passthrough, or the fax may fail.

**Gateway version mismatch.** T.38 has multiple versions, and the parameters in the SDP (max bit rate, error correction mode, rate management) must be compatible between both sides. A mismatch can cause the re-INVITE to succeed but the actual T.38 session to fail when data transfer begins.

**Timing problems.** The re-INVITE must complete before the fax machines advance past the initial handshake phase. If the re-INVITE takes too long (because of network latency, SIP proxy delays, or slow endpoint processing), the fax machines may time out and drop the session. Some fax machines are more tolerant of this delay than others.

**Firewalls blocking UDPTL.** UDPTL uses UDP but on different ports than RTP. If your firewall is configured to allow RTP on specific port ranges but does not account for UDPTL, the T.38 data will be blocked even though the SIP signaling succeeded. The result is a successful T.38 negotiation followed by no data flowing: the fax hangs and eventually times out.

**NAT complications.** The same [NAT traversal issues](/blog/sip-nat-traversal) that affect RTP also affect UDPTL, but NAT devices are less likely to handle UDPTL correctly because it is a less common protocol. SIP ALGs that rewrite RTP addresses in SDP may not know how to handle T.38 SDP.

## Error Correction Mode (ECM)

ECM is a feature of the T.30 fax protocol (the protocol that fax machines speak to each other) that adds error detection and retransmission at the fax layer. When ECM is enabled, the sending fax machine breaks each page into blocks, sends them with error-checking data, and the receiving machine requests retransmission of any corrupted blocks.

ECM works well with T.38 because the combination provides error correction at two layers: UDPTL redundancy handles packet loss on the network, and ECM handles any residual data errors in the fax content. With both enabled, fax reliability over VoIP improves significantly.

ECM is less helpful with fax passthrough because the audio path does not have the same redundancy mechanisms. If a packet is lost during passthrough, the modem tone is damaged, and ECM may trigger retransmissions. But if the network is consistently lossy, ECM retransmissions can slow the fax to a crawl or cause it to fail after exhausting retries.

Most modern fax machines support ECM by default, and on a clean path it is the right setting. But if you are troubleshooting fax failures on a path with jitter or packet loss, try disabling ECM as a diagnostic step rather than confirming it is on: [Cisco's fax relay troubleshooting guidance on ECM](https://www.cisco.com/c/en/us/support/docs/voice/fax-modem-over-ip/20227-faxrelay-tsguide.html) puts ECM's tolerance at roughly 2% loss and jitter, while transmissions with ECM disabled complete at markedly higher loss rates: the pages may carry errors, but they complete.

## Troubleshooting T.38

**Fax detected but call drops immediately.** The re-INVITE is probably being rejected. Check your SIP traces to see the response to the re-INVITE. A 488 or 606 response means the far end does not support T.38. Configure your gateway to fall back to passthrough.

**Fax connects but pages fail.** T.38 is negotiated but data is not flowing correctly. Check for firewall blocking UDPTL, NAT issues with UDPTL ports, or a gateway mismatch in T.38 parameters. Capture packets and look for UDPTL traffic on the negotiated port.

**Fax is very slow.** The fax machines are probably falling back to lower speeds due to errors. With T.38, this suggests the UDPTL redundancy is not fully compensating for network loss. Check the network path for packet loss. With passthrough, it suggests the audio path has enough jitter or loss to cause frequent retransmissions.

**Intermittent failures.** Some faxes work, some do not. This often indicates a borderline network condition: enough impairment to occasionally corrupt data but not enough to fail consistently. It can also indicate a T.38 compatibility issue with specific remote fax machines or gateways. Test with multiple destinations to narrow down whether the problem is local or specific to certain remote endpoints.

## When to use which

Use T.38 when your equipment and provider both support it reliably. T.38 handles network impairment better than passthrough and is the right choice for any environment where fax reliability matters.

Use passthrough when T.38 is not available or when T.38 is causing more problems than it solves (failed re-INVITEs, gateway incompatibilities). Configure passthrough with G.711 only (never compressed codecs), echo cancellation disabled, silence suppression disabled, and jitter buffer set to fixed mode.

Use a dedicated fax-over-IP service (like an e-fax provider) when fax volume is low and you want to avoid the complexity of either approach entirely. These services handle the T.38 or passthrough mechanics on their end and deliver faxes as email attachments.

Or, increasingly, stop faxing. The number of situations that genuinely require fax is shrinking. But if your organization still depends on it (and many in healthcare, legal, and government do), understanding T.38 is the difference between faxes that work and faxes that fail with no clear explanation.

---

## How Codecs Shape Call Quality

URL: https://voiptest.com/blog/how-codecs-shape-call-quality
Published: 2026-05-19
Category: Fundamentals
Tags: codec, g711, g729, opus, call-quality, bandwidth, voip-fundamentals

Every VoIP call passes through a codec. The codec determines how your voice is converted from an analog signal into digital data, how much that data is compressed, and how much bandwidth the resulting stream requires. It is one of the most important factors in call quality, and it is one that most people never think about because it is negotiated automatically between endpoints before the first word is spoken.

Understanding codecs is not about memorizing bitrate tables. It is about understanding why the same network conditions produce different call quality depending on which codec is in use, and why choosing the right codec for your environment matters more than most network optimizations. If you want to know what conditions your codec actually has to survive, a [VoIP quality test](/tools/voip-test) measures the packet loss and jitter on your real network path.

## What a codec does

The word "codec" is short for coder-decoder. The coder side takes analog audio from a microphone, samples it at regular intervals, and converts those samples into digital data. The decoder side takes the digital data and converts it back to analog audio for the speaker.

Between coding and decoding, some codecs also compress the data. Compression reduces bandwidth but introduces artifacts and makes the audio more fragile in the face of [packet loss](/blog/understanding-voip-packet-loss) and [jitter](/blog/latency-jitter-packet-loss-details). This is the fundamental tradeoff in codec selection: bandwidth versus quality versus resilience.

Every codec produces a stream of [RTP packets](/blog/how-data-moves-in-packets) at regular intervals. The most common interval is 20 milliseconds, meaning 50 packets per second in each direction. Some codecs support different packet intervals (ptime), which affects packet count and per-packet overhead.

## The major codecs

### G.711 (u-law and a-law)

G.711 is the reference standard for VoIP audio quality. It [samples audio at 8kHz and uses 8 bits per sample](https://www.rfc-editor.org/rfc/rfc3551.html) with no compression, producing a constant 64kbps stream. With IP, UDP, and RTP headers added, a G.711 call uses 80kbps in each direction at the standard 20ms ptime, or about 87kbps once Ethernet framing is counted as well. Which figure you want depends on where you are sizing: the IP number for WAN and trunk capacity, the Ethernet number for switches and the LAN.

There are two variants. G.711 u-law (also written μ-law) is used in North America and Japan. G.711 a-law is used in the rest of the world. The difference is in the companding algorithm used to map the analog signal to 8-bit samples. Both produce equivalent quality.

G.711's strengths are simplicity and predictability. There is no compression algorithm to introduce artifacts. No processing delay beyond the packetization interval. No variability in output quality based on audio content. What goes in comes out, minus whatever the network does to the packets in transit.

Its weakness is bandwidth. At 87kbps per call, G.711 uses roughly three times the bandwidth of compressed codecs. For most modern business internet connections, this is irrelevant: 100 simultaneous G.711 calls need less than 9Mbps. But on constrained links or high-density deployments, the bandwidth adds up. A [bandwidth calculator](/tools/bandwidth-calculator) can show you the exact per-call overhead for each codec so you can plan accordingly.

G.711 losses are also comparatively simple to conceal, though that is not the same as being the most resilient narrowband codec. At the same ptime, a lost packet removes the same duration of audio under any codec. What differs is how hard the gap is to hide: G.711 packets carry independent uncompressed samples, so the receiver can fill the gap with basic interpolation (repeating the last good frame), whereas predictive codecs additionally lose decoder state with each missing packet and take longer to recover.

That is one factor among several, not a ranking. How bad a given loss actually sounds also depends on the receiver's packet loss concealment implementation, whether losses arrive in bursts or isolated, whether FEC or redundancy is in use, the bitrate, and the specific stack at each end. Two devices running the same codec on the same impaired path can sound noticeably different.

### G.729

[G.729](https://www.itu.int/rec/T-REC-G.729) compresses voice audio to 8kbps, roughly one-eighth of G.711's bitrate. With packet overhead, a G.729 call uses about 24kbps at the IP layer, or 32kbps on Ethernet: the headers cost the same regardless of how small the payload is, which is most of why the eightfold payload saving does not translate into an eightfold bandwidth saving. This made G.729 essential in the early days of VoIP when bandwidth was expensive and limited.

The compression works by modeling the human vocal tract and encoding a set of parameters that describe the speech rather than encoding the raw audio samples. The decoder uses these parameters to synthesize audio that sounds like the original. This is CELP (Code-Excited Linear Prediction) coding; the ITU-T names G.729's variant specifically as CS-ACELP, conjugate-structure algebraic-code-excited linear prediction.

The result sounds good for voice: clear and intelligible for most speakers in most conditions. But it does not sound like G.711. Compression artifacts are present, particularly on non-speech audio. Hold music, DTMF tones, modem signals, and [fax transmissions](/blog/fax-over-ip) all suffer noticeably through G.729 because the vocal tract model does not describe them well.

G.729 is more sensitive to packet loss than G.711. Not because a G.729 packet carries more milliseconds of audio (at the same ptime it carries exactly the same duration) but because each packet encodes a compressed representation rather than raw samples, and the decoder needs context from surrounding packets to reconstruct the signal accurately. A lost packet creates a gap of the same length that is harder to conceal. So at the same loss rate, especially when the losses come in bursts rather than randomly, a G.729 call degrades more than a G.711 call does, because concealment has less to work from.

G.729 was historically encumbered by patents, which required licensing fees. Those patents have expired, but the codec's market position has been largely supplanted by Opus for new deployments.

### G.722

G.722 is the standard wideband codec, sampling audio at 16kHz instead of 8kHz. The higher sample rate captures frequencies up to 7kHz (compared to 3.4kHz for narrowband codecs), producing noticeably richer, more natural-sounding voice. This is what marketing calls "HD Voice."

G.722 uses 64kbps, the same as G.711, but at wideband quality. This seems like a free upgrade, and in many environments it is. The catch is that both endpoints and every intermediate device must support G.722. If a call leg transits through a system that only supports narrowband codecs, the call will be transcoded down and the wideband quality is lost.

G.722 is widely supported on modern desk phones and softphones. If your VoIP provider and all your endpoints support it, it is worth enabling for the quality improvement.

### Opus

Opus is the modern standard for real-time audio. It supports both narrowband and wideband audio, adjusts its bitrate dynamically based on network conditions, and includes sophisticated packet loss concealment. It was designed for the internet rather than adapted from telephone network standards.

Opus operates at bitrates from about 6kbps to 510kbps, with typical voice configurations using 24-48kbps. At the low end, it outperforms G.729 in quality at comparable bitrates. At the high end, it delivers wideband quality that exceeds G.722. Its adaptive bitrate capability means it can lower its bitrate on the fly when the network degrades, which is *more* compression, not less, trading audio richness for a stream that fits through congestion. Resilience comes from a separate set of tools the codec was designed with: in-band forward error correction, packet loss concealment, and DTX (RFC 6716).

The packet loss concealment in Opus is significantly more advanced than older codecs. Its in-band FEC ([RFC 6716](https://www.rfc-editor.org/rfc/rfc6716.html)) encodes a redundant low-bitrate copy of each frame into the following packet, allowing the decoder to reconstruct lost packets, provided the feature is enabled and signaled between the endpoints (the `useinbandfec` parameter of RFC 7587). That is a different mechanism from the concealment older codecs rely on: FEC reconstructs the lost frame rather than masking its absence, which is why Opus with FEC can hold up at moderate loss rates while using less bandwidth than G.711.

Opus is standard in browser-based calling and is increasingly supported by SIP-based VoIP platforms. Its main limitation is that older PBX systems, SIP trunking providers, and desk phones may not support it. Calls between an Opus-capable softphone and a provider that only supports G.711 will negotiate down to G.711.

### Other codecs you may encounter

**iLBC (internet Low Bitrate Codec).** Designed specifically for packet loss resilience at low bitrates (13.3 or 15.2 kbps). Each packet is independently decodable, meaning a lost packet does not affect surrounding audio. Rarely used in new deployments but occasionally seen in legacy browser-calling applications.

**GSM.** The codec from mobile phone networks, sometimes used in low-bandwidth VoIP. Quality is acceptable for voice but noticeably compressed. Mostly a legacy choice.

**G.726.** An ADPCM codec that offers bitrates between G.711 and G.729 (16, 24, 32, or 40 kbps). Occasionally used but largely superseded by more modern options.

## How codec negotiation works

When a VoIP call is initiated, the calling endpoint sends an INVITE message containing an [SDP body that lists its supported codecs](/blog/sdp-media-negotiation) in order of preference. The receiving endpoint responds with its own SDP indicating which codec it has chosen from the offered list.

If the two endpoints share no common codec, the call fails. If they share multiple codecs, the answering endpoint typically selects the highest-preference codec that both support.

This negotiation is why you can have a phone configured for Opus that seamlessly falls back to G.711 when calling a provider that does not support Opus. The phone offered both, the provider selected G.711, and the call proceeds at narrowband quality. No error, no warning: just a silent quality downgrade that neither party may notice unless they are listening for it.

## Transcoding: the hidden quality tax

When a call passes through a system that needs to convert between codecs (say, the inbound leg uses Opus but the outbound trunk only supports G.711) the system must decode the audio from one codec and re-encode it in the other. This is transcoding.

Transcoding introduces three costs. First, processing load: decoding and re-encoding audio in real time requires CPU resources. At scale, this can be significant. Second, latency: the transcode step adds a small but nonzero delay. Third, and most important, quality loss. Every compression and decompression cycle introduces artifacts. A call that is compressed with G.729, decompressed, then recompressed with G.711 sounds worse than a call that used either codec end-to-end.

Transcoding between two lossy codecs is the worst case. The artifacts from the first codec are baked into the audio signal. The second codec then compresses that already-degraded signal, adding its own artifacts on top. The result is [audibly degraded](/blog/choppy-robotic-audio) in a way that neither codec would produce on its own.

Avoiding unnecessary transcoding is one of the simplest ways to improve call quality. Use the same codec end-to-end when possible. If your provider's trunk supports G.711 and your phones support G.711, configure G.711 as the preferred codec and eliminate the transcode.

## Choosing the right codec

The choice depends on your specific constraints.

**If bandwidth is not a concern** (most modern offices), use G.711 for maximum compatibility and consistent quality, or G.722/Opus for wideband quality if your entire call path supports it.

**If bandwidth is constrained** (remote sites on limited links, high-density call centers), G.729 reduces bandwidth significantly at an acceptable quality tradeoff. Opus at a constrained bitrate is a better choice if your infrastructure supports it.

**If packet loss is a known issue** (and you cannot fix it), Opus with in-band FEC enabled is the strongest starting point, because it can reconstruct some lost audio rather than only conceal it. G.711 is a reasonable fallback given how simple its gaps are to conceal, and G.729 tends to fare worst because each loss also costs decoder state. Treat that as an ordering to test rather than a guarantee: the concealment quality of your particular endpoints, and whether your loss is bursty or isolated, can matter more than the codec choice.

**If you are mixing endpoints** (desk phones, softphones, mobile clients, browser clients), you will likely end up with multiple codecs in play. Make sure your PBX or provider handles the negotiation cleanly and minimize transcoding by aligning codec preferences across endpoint types.

The codec is not usually the first thing to troubleshoot when calls sound bad. Network conditions ([jitter](/blog/what-is-jitter-and-why-it-matters), loss, congestion) cause the majority of quality problems regardless of codec. But the codec determines how gracefully the audio degrades when network conditions are imperfect, and it sets the ceiling on your [MOS score](/blog/understanding-mos-scores): even a perfect network cannot push G.729 past roughly 3.9, and you can watch how each codec moves the score under loss and jitter in the [MOS Explorer](/tools/mos-explorer). Understanding [why voice is uniquely demanding](/blog/why-voice-is-hard) and how your codec choice interacts with your network reality is part of building a VoIP deployment that sounds good consistently, not just when conditions are ideal.

---

## Testing VoIP Before You Deploy: A Pre-Flight Checklist

URL: https://voiptest.com/blog/voip-pre-flight-checklist
Published: 2026-05-18
Category: Guides
Tags: voip-deployment, network-testing, pre-flight, checklist, call-quality, msp

The best time to discover a VoIP problem is before users are on the system. Every deployment should go through a structured pre-flight check that validates the full stack (internet, LAN, firewall, DNS, endpoints, and actual call quality) before anyone dials a real phone number.

This checklist is organized by layer, from the internet connection down to individual handsets. Work through it in order. A failure in an earlier section often causes failures in later sections, so fix issues as you find them rather than pressing forward.

If you are an MSP, this complements your [network assessment](/blog/msp-network-assessment) and [network preparation](/blog/msp-network-preparation) work. If you have done those steps, some of these items will be a confirmation of work already completed. That is fine. Verify anyway.

## Internet connection

A [speed test cannot tell you if VoIP will work](/blog/why-speed-tests-cant-measure-voip). You need to test [the metrics that actually matter for voice](/blog/voip-quality-testing-guide): jitter, packet loss, latency, and MOS.

- [ ] **Jitter under 20ms.** Test with a UDP-based tool that sends packets at VoIP-like intervals (every 20ms). Run the test for at least 5 minutes during peak business hours. As an operating target, average jitter should be under 20ms with no sustained spikes above 50ms; these are practical objectives, not protocol thresholds, since the audible impact depends on the endpoint's jitter buffer.

- [ ] **Packet loss under 0.5%.** Measure loss over the same UDP test. Any consistent loss is a problem. Occasional isolated drops may be tolerable, but [burst loss](/blog/understanding-voip-packet-loss) is worse than random loss at the same percentage.

- [ ] **Latency under 100ms one-way.** Measure round-trip time to your VoIP provider's SIP servers or a representative internet destination. Divide by two for approximate one-way latency. Under 100ms one-way is a comfortable operating target. ITU-T G.114 cites 150ms one-way as a planning boundary for conversational speech: not a point where audio fails, but beyond it people increasingly [start talking over each other](/blog/audio-delay-talking-over).

- [ ] **Test during peak hours.** Run tests at 10am, 2pm, and 4pm on a business day. Internet quality varies with usage. A test at 6am on a Sunday tells you nothing about what Tuesday afternoon will look like.

- [ ] **Test under load.** If possible, generate typical business traffic (file transfers, cloud app usage, backups) while running the voice quality test. You need to know how voice performs when the connection is actually being used, not when it is idle.

## LAN readiness

The internal network carries voice packets from the phone to the router. Every component in that path matters.

- [ ] **Voice VLAN configured.** Phones should be on a [dedicated VLAN](/blog/office-network-vlans) separate from data traffic. Verify that the VLAN is configured on every switch port where a phone will connect, and that the DHCP scope for the voice VLAN is issuing addresses correctly.

- [ ] **QoS enabled and verified.** [QoS markings](/blog/office-network-qos) should be configured on your managed switches and router. Verify that voice packets are being marked with DSCP 46 (EF) and that the router's outbound interface has a priority queue for marked traffic. Note that QoS only protects voice on your local network; ISPs strip these markings at their network edge.

- [ ] **PoE budget verified.** If phones draw power from the [switch via PoE](/blog/office-network-poe), confirm that the switch's total PoE budget can handle all connected phones plus any other PoE devices (access points, cameras). A switch running out of PoE budget will silently refuse to power additional phones.

- [ ] **Switch uplink capacity.** The uplink from your access switch to your core switch or router should not be a bottleneck. If 48 phones share a single gigabit uplink to the router, the uplink is fine. If the uplink is 100Mbps and you have 200 phones, do the math. Check your [switch configuration](/blog/office-network-switches) for any port speed mismatches.

- [ ] **Cabling tested.** Every cable run to a phone location should be tested with a cable certifier or at minimum verified to link at the expected speed. A cable that negotiates 100Mbps instead of 1Gbps due to a bad termination will work but may introduce problems under load.

## Firewall and NAT

Firewalls are the single most common source of VoIP deployment problems.

- [ ] **SIP ALG disabled.** Check your router and firewall for SIP ALG (Application Layer Gateway). It should be off. SIP ALG rewrites SIP messages as they cross NAT and almost always introduces more problems than it solves: [one-way audio](/blog/one-way-audio), registration failures, dropped calls. Disable it.

- [ ] **SIP signaling ports open.** Your VoIP provider will specify which ports and transports SIP uses: 5060 for UDP/TCP and 5061 for SIP over TLS are the conventional defaults (RFC 3261), but the actual values come from your provider's configuration and DNS. Confirm that outbound traffic to your provider on these ports is permitted and that return traffic is allowed through the stateful firewall.

- [ ] **RTP media path verified.** RTP (the actual audio) uses a range of UDP ports: 10000-20000 is a common convention, but the actual range comes from your provider's configuration and the SDP, not a standard. Outbound UDP to your provider's media addresses must be permitted; return audio should ride the stateful pinhole that outbound traffic opens, so avoid blanket inbound "allow UDP 10000-20000 from anywhere" rules. If your provider requires explicit inbound rules, scope them to the provider's published media source IPs, or put an SBC at the edge and grant it least-privilege access. Some firewalls with overly aggressive UDP timeouts will drop RTP sessions; verify that your firewall's UDP session timeout is at least 60 seconds.

- [ ] **NAT traversal tested.** If phones are behind NAT (they almost always are), verify that [NAT traversal](/blog/sip-nat-traversal) is working. The phones should register successfully and maintain registration. Place a test call and confirm audio flows in both directions.

- [ ] **No SIP inspection interfering.** Some enterprise firewalls have SIP-aware inspection engines (separate from SIP ALG) that can also interfere with signaling. If you have a next-gen firewall, check whether its SIP inspection is modifying packets.

## DNS

[DNS failures](/blog/dns-and-voip) take down VoIP completely because phones need to resolve your provider's SIP server hostname to register.

- [ ] **SIP server hostname resolves.** From the voice VLAN, verify that your VoIP provider's SIP server FQDN resolves correctly. Check for both A records and SRV records if your provider uses them.

- [ ] **DNS response time under 50ms.** Slow DNS does not usually affect call quality, but it can slow registration and failover. Verify that your DNS server responds promptly from the voice VLAN.

- [ ] **Secondary DNS works.** If your primary DNS server goes down, phones need to reach a secondary. Verify that the secondary is configured in your DHCP scope for the voice VLAN and that it resolves the same records.

## Failover and redundancy

Do not wait for a real outage to find out if your [failover](/blog/redundancy-failover) works.

- [ ] **Secondary ISP tested.** If you have a backup internet connection, simulate a primary failure (unplug it) and verify that traffic fails over. Place a call over the backup connection and confirm quality is acceptable. Some backup connections (LTE, satellite) may have latency or loss characteristics that degrade voice quality.

- [ ] **VoIP provider failover tested.** If your provider has multiple SIP servers or registrar addresses, verify that phones fail over to the secondary when the primary is unreachable. Simulate this by blocking the primary server's IP in your firewall temporarily.

- [ ] **Recovery tested.** After failover, restore the primary path and verify that phones fail back correctly. Some configurations require manual intervention to return to the primary. Find out now, not during an outage.

## Endpoint provisioning

Every phone needs to be individually verified. Bulk provisioning saves time but introduces bulk problems if the template is wrong.

- [ ] **All phones registered.** Every phone should show a registered status on its display or web interface. An unregistered phone cannot make or receive calls. Check your VoIP provider's portal for registration status of all extensions.

- [ ] **Firmware current.** Verify that phones are running the firmware version recommended by your provider or manufacturer. Outdated firmware is a common source of intermittent issues that are difficult to troubleshoot.

- [ ] **Time and date correct.** Phones that cannot reach an NTP server will have incorrect time, which can affect TLS certificate validation and call detail record accuracy. Certificates deserve their own line on any checklist: [expired VoIP certificates](/blog/voip-certificate-expiration) cause silent registration failures that look like network problems.

- [ ] **Features configured.** BLF keys, speed dials, call park buttons, shared lines, paging groups. Whatever was specified in the deployment plan should be verified on each phone.

## Test calls

This is where you find out if everything actually works together.

- [ ] **Internal call (extension to extension).** Two phones on your network calling each other. Audio should be clear in both directions. This tests your LAN and your provider's call routing.

- [ ] **External call (outbound to mobile).** Call a mobile phone. Verify audio quality, caller ID display, and that DTMF tones work (press options on a voicemail system or automated attendant).

- [ ] **External call (inbound from mobile).** Call into your main number from a mobile phone. Verify the auto-attendant or receptionist answers, the call routes correctly, and audio is clear.

- [ ] **Call transfer (blind and attended).** Transfer a call to another extension both ways. A failed transfer during testing is a configuration fix. A failed transfer during a client call is an embarrassment.

- [ ] **Hold and resume.** Place a call on hold, verify hold music plays for the other party, resume the call. Hold failures are a common SIP interoperability issue.

- [ ] **Conference call.** Initiate a three-way call. Verify all parties can hear each other.

- [ ] **Voicemail.** Call an extension that does not answer and verify the call reaches voicemail. Leave a message and verify the notification (email, phone indicator) works.

## Number porting readiness

If you are [porting numbers](/blog/how-number-porting-works), you have a hard cutover date that cannot be easily reversed.

- [ ] **FOC (Firm Order Commitment) confirmed.** You have a confirmed date from the losing carrier. The port will happen on that date whether you are ready or not.

- [ ] **Temporary numbers tested.** Before the port, test everything using the temporary numbers your new provider assigned. Every issue you find and fix before porting day is one less thing that can go wrong during the cutover.

- [ ] **Porting day plan documented.** Who will be on-site? Who is the contact at the new provider? What is the rollback plan if the port fails? Document this before [go-live day](/blog/msp-go-live-day), not during it.

## Monitoring

You need to know when something breaks, ideally before users tell you.

- [ ] **Registration monitoring active.** Your [monitoring system](/blog/msp-proactive-monitoring) should alert if any phone loses registration.

- [ ] **Quality metrics being collected.** RTCP reports, call quality scores, or endpoint statistics should be flowing to your monitoring platform. Verify that data is actually arriving and that dashboards show current information.

- [ ] **Alert contacts verified.** Whoever receives alerts should confirm they are getting test notifications. An alerting system that silently fails to deliver alerts is worse than no alerting at all.

Every item on this checklist is something that has gone wrong in a real VoIP deployment. Working through it systematically before go-live does not guarantee a perfect launch, but it eliminates the categories of problems that are preventable, predictable, and embarrassing. The problems you cannot prevent (ISP outages, provider issues, edge cases in call routing) are hard enough to deal with without also fighting configuration mistakes you could have caught the week before.

---

## How to Disable SIP ALG: A Guide by Router Vendor

URL: https://voiptest.com/blog/sip-alg-router-guide
Published: 2026-05-17
Category: Troubleshooting
Tags: sip-alg, router, troubleshooting, one-way-audio, nat, firewall

SIP ALG is the single most common cause of VoIP problems on business networks, and it has been for over a decade. It ships enabled by default on nearly every router sold, and it will keep breaking your calls until you explicitly turn it off.

The concept behind SIP ALG is reasonable: inspect SIP packets as they cross the router and rewrite the headers so they work correctly through NAT. In practice, the implementations are buggy, outdated, and they break more than they fix. Modern VoIP endpoints handle NAT traversal themselves using STUN, symmetric RTP, and outbound proxy configurations. SIP ALG interferes with these mechanisms by rewriting headers that were already correct.

For the full explanation of why SIP ALG causes problems, see [SIP ALG: The Router Setting That Breaks Everything](/blog/sip-alg-the-setting-that-breaks-everything). This post is the practical companion: where the control lives on the vendors you are most likely to encounter.

### How to use this guide

Menu paths and CLI syntax for these settings move between firmware releases, and the same brand often behaves differently across model families. Treat everything below as **a starting point that tells you what to look for and what it is called, then confirm it against your vendor's current documentation for your exact model and firmware version.** These steps have not been verified against every model and release, and any guide that claims otherwise (including an earlier version of this one) is overstating what it can know.

Two rules that matter more than any individual menu path:

- **Only change the SIP ALG control itself.** A recurring pattern in SIP ALG guides is to reach for some adjacent, broader setting when the ALG switch cannot be found: opening up NAT filtering, disabling packet normalization, exempting traffic from connection tracking. These are not equivalent to disabling an ALG. They generally will not stop header rewriting, and they weaken protections that apply to all your traffic. Where that substitution commonly gets suggested, this guide flags it.
- **If your vendor exposes no supported SIP ALG control, that is a real answer.** It means the fix lives elsewhere: your provider's NAT-traversal guidance (outbound proxy, keepalives, STUN), or putting a supported router or SBC in front of the phones. It does not mean you should improvise one.

## The symptoms

Before you start changing settings, confirm that SIP ALG is likely the culprit. The classic pattern:

- **One-way audio**: you can hear the other party but they cannot hear you, or vice versa. This is the most common symptom. See [One Way Audio: I Can Hear Them But They Can't Hear Me](/blog/one-way-audio) for a deeper dive.
- **Calls fail on transfer**: a call connects fine, but when transferred to another extension or external number, the audio drops or the call disconnects.
- **Intermittent registration failures**: phones randomly go unregistered and then re-register on their own.
- **No audio in either direction**: the call connects (you see it ringing and answered) but neither side can hear anything.
- **Calls work on the same network but fail to external numbers**: internal extension-to-extension calls are fine, but calls through a SIP trunk fail.

If you are seeing these symptoms and the phones are behind a NAT router, SIP ALG is the first thing to check.

## How to prove it

The definitive test is a packet capture on both sides of the router. Capture on the LAN side (between the phone and the router) and on the WAN side (between the router and the internet). Compare the SIP INVITE messages. If the Contact header, Via header, or SDP connection address has been rewritten between the two captures, SIP ALG is active and modifying your traffic.

You can upload both captures to our [PCAP analyzer](/tools/pcap-analyzer) to compare the SIP headers side by side without manually digging through Wireshark.

The faster test: disable SIP ALG, reboot the router, and see if the problem goes away. If it does, you have your answer.

One caution before the vendor sections: menu paths and CLI syntax vary by model and firmware release, sometimes significantly. Treat the instructions below as a map, verify them against your vendor's current documentation for your exact model and firmware version before pasting commands, and prefer the vendor's supported setting over any workaround found in a forum thread.

## Ubiquiti (UniFi / EdgeRouter)

### UniFi Security Gateway and UniFi Dream Machine

On the USG, which runs EdgeOS underneath, the ALG lives in the kernel's connection tracking SIP module. SSH into the gateway and run:

```
configure
set system conntrack modules sip disable
commit
save
```

Because the controller re-provisions the USG's configuration, a change made over SSH will be overwritten on the next provision; persist it through the controller's `config.gateway.json` mechanism (documented by Ubiquiti) so it survives.

On UDM and UDM Pro running UniFi OS, whether a supported SIP ALG setting exists (and where it lives) depends on your UniFi OS and UniFi Network application versions, so check Ubiquiti's current documentation for your firmware. One thing not to do: forum threads circulate raw `iptables` `NOTRACK` rules for UDP port 5060 as a do-it-yourself ALG disable. Do not use them. `NOTRACK` exempts matching packets from connection tracking entirely, which is not the same thing as disabling ALG inspection: it can break NAT and stateful firewalling for exactly the traffic you are trying to fix, and the rules silently vanish on firmware upgrades. If your firmware exposes no supported control, the reliable paths are your VoIP provider's NAT-traversal guidance (outbound proxy, keepalives), a supported router or SBC in front of the phones, or Ubiquiti support.

### EdgeRouter

SSH in or use the CLI tab in the EdgeRouter web interface (EdgeOS documented command):

```
configure
set system conntrack modules sip disable
commit
save
```

Then reboot the router. The conntrack SIP module is what performs ALG inspection. Disabling it stops the packet mangling.

## Fortinet (FortiGate)

FortiGate firewalls have SIP ALG enabled by default through the SIP Application Layer Gateway and the SIP session helper.

In the FortiGate CLI:

```
config system settings
    set sip-helper disable
    set sip-nat-trace disable
    set default-voip-alg-mode kernel-helper-based
end

config system session-helper
    show
```

Find the entry for SIP (port 5060) and delete it:

```
config system session-helper
    delete <id>
end
```

Replace `<id>` with the number shown next to the SIP entry. Then reboot. Some FortiOS versions also require disabling the SIP inspection profile in the firewall policy if one is applied:

```
config firewall policy
    edit <policy_id>
        set voip-profile ""
    next
end
```

## SonicWall

SonicWall firewalls have "Consistent NAT" and "SIP Transformations" that act as SIP ALG.

In the web management interface:

1. Navigate to **Voice > Settings** (on older firmware: **VoIP > Settings**)
2. Uncheck **Enable SIP Transformations** (this is the ALG control)
3. Under **Network > NAT Policies**, verify there are no NAT policies specifically manipulating SIP traffic
4. Apply and reboot

Separately from the ALG, SonicWall's **Consistent NAT** option (**Network > Firewall > Advanced**) changes how the appliance maps source ports for UDP, which some VoIP deployments prefer. It is a NAT behaviour setting, not an ALG control, so change it deliberately and on its own, not as a substitute for step 2 if you cannot find that setting.

On Gen 7 SonicWall (SonicOS 7.x), the path is **Policy > Security Services > VoIP** and the setting is **Enable SIP ALG**.

## Netgear

Most Netgear consumer and prosumer routers have SIP ALG buried in the settings.

In the web interface:

1. Navigate to **Advanced > WAN Setup** (or **Advanced > Setup > WAN Setup**)
2. Look for a **Disable SIP ALG** checkbox; check it to disable
3. Apply and reboot

On Netgear Nighthawk and Orbi models, the setting is usually under **Advanced > WAN Setup > Disable SIP ALG**.

**Do not substitute the NAT Filtering setting for this.** Some guides suggest switching **NAT Filtering** from **Secured** to **Open** when no SIP ALG checkbox is present. That is a different control: it broadly relaxes which inbound traffic the router accepts, weakening your firewall posture, and it does not stop ALG inspection from rewriting SIP headers. If your model exposes no SIP ALG control, treat it as a model without one and use the fallbacks at the end of this guide.

## TP-Link

### Consumer routers (Archer series)

1. Log into the router admin (usually 192.168.0.1 or tplinkwifi.net)
2. Navigate to **Advanced > NAT Forwarding > ALG**
3. Uncheck **SIP ALG** (and **H.323 ALG** if present)
4. Save and reboot

### Omada (managed)

In the Omada controller:

1. Go to **Settings > Network > Service** (or **Gateway > ALG** depending on firmware)
2. Disable **SIP ALG**
3. Apply

## Cisco (Meraki, ISR, ASA)

### Meraki MX

Meraki does not expose a traditional SIP ALG toggle. That means there is no ALG to disable here, so if SIP is misbehaving through an MX, you are looking for a different cause rather than a hidden ALG switch. Content filtering and IPS are the usual candidates:

1. In the Meraki dashboard, go to **Security & SD-WAN > Firewall**
2. Ensure UDP 5060 and your RTP range (typically 10000-20000) are allowed outbound
3. Under **Threat Protection**, check whether SIP traffic is being flagged or dropped by IDS/IPS
4. Confirm with your VoIP provider whether their platform expects a specific NAT or keepalive behaviour on this path

If none of that resolves it, consult Meraki's current documentation for your MX model and firmware rather than applying a control borrowed from another vendor.

### Cisco ISR (IOS)

```
no ip nat service sip udp port 5060
no ip nat service sip tcp port 5060
```

Save the config and reload.

### Cisco ASA

```
policy-map global_policy
 class inspection_default
  no inspect sip
```

Then `write memory` and reload.

## Mikrotik (RouterOS)

Mikrotik routers have a SIP helper in the connection tracking module.

In the terminal:

```
/ip firewall service-port set sip disabled=yes
```

Or in WinBox: **IP > Firewall > Service Ports**, find `sip`, and disable it.

## pfSense / OPNsense

pfSense has no SIP ALG to disable. What it does have is outbound NAT that randomizes source ports by default, which some SIP endpoints and providers cope with poorly, a different problem with a different fix:

1. Navigate to **Firewall > NAT > Outbound**
2. If using **Automatic Outbound NAT**, switch to **Hybrid** or **Manual** so you can add your own rule
3. Create a rule for your VoIP subnet with **Static Port** enabled, which stops the source port being rewritten

OPNsense: same approach, same path (**Firewall > NAT > Outbound**).

**Leave Firewall Scrub alone.** Scrub is packet normalization (it reassembles fragments and sanitizes malformed packets), and disabling it is sometimes suggested as a SIP fix. It is not an ALG control, disabling it will not stop header rewriting (there is none happening here), and it removes a protection that applies to all your traffic, not just SIP. If static port does not resolve the issue, the cause is somewhere other than pfSense's packet filter.

## ISP-provided routers

If you are using a router provided by your ISP (AT&T BGW, Comcast xFi, Verizon Fios), SIP ALG may be enabled and the setting may not be exposed in the consumer interface.

Your options:

1. **Check for an advanced settings page.** Some ISP gateways expose more options (sometimes including SIP ALG) in an advanced or technician-level settings area that is not linked from the main interface. Check your ISP's documentation for your gateway model rather than relying on URLs from forum posts, which change between firmware revisions.
2. **Enable IP Passthrough / Bridge Mode.** Put the ISP router in bridge mode and use your own router behind it. This bypasses the ISP router's NAT and ALG entirely.
3. **Call the ISP.** Some ISPs can disable SIP ALG remotely. Worth asking, though success varies.

Bridge mode is the most reliable option. It also gives you control over your firewall, NAT, and QoS settings, which matters for VoIP quality.

## After disabling SIP ALG

After disabling SIP ALG on any router:

1. **Reboot the router.** Settings changes to NAT helpers and connection tracking modules typically require a reboot to take full effect.
2. **Restart your phones or PBX.** Force a fresh SIP registration so the new (unmangled) headers are used.
3. **Test calls.** Make a call to an external number. Test a transfer. Test a call on hold. These are the scenarios most affected by SIP ALG.
4. **Run a VoIP quality test.** Use our [VoIP quality test](/tools/voip-test) to verify that media (RTP) is flowing correctly in both directions with acceptable jitter and packet loss.

If the problems persist after disabling SIP ALG, the issue may be elsewhere: [double NAT](/blog/double-nat-voip), restrictive firewall rules, or a network quality problem. See [How to Tell Where the Problem Actually Is](/blog/diagnosing-voip-problems) for a systematic troubleshooting approach.

*For the full technical explanation of why SIP ALG causes these problems, see [SIP ALG: The Router Setting That Breaks Everything](/blog/sip-alg-the-setting-that-breaks-everything). For help reading the SIP traces that reveal ALG mangling, see [Reading a SIP Trace: Practical Troubleshooting](/blog/reading-a-sip-trace).*

---

## What a Packet Capture Actually Tells You About a Bad Call

URL: https://voiptest.com/blog/what-packet-capture-tells-you
Published: 2026-05-16
Category: Technical
Tags: packet-capture, wireshark, rtp, troubleshooting, call-quality, network-analysis

There is a point in every VoIP troubleshooting process where the logs stop being useful and you need to see what is actually happening on the wire. That is when you pull a packet capture.

A packet capture (pcap) records every packet flowing through a network interface. For VoIP, that means you can see the exact SIP messages that set up and tear down calls, the exact RTP packets that carry audio, and the precise timing of every packet arrival. It is the closest thing to ground truth you can get when diagnosing call quality problems.

But a pcap file full of thousands of packets is only useful if you know what to look for. This is a practical guide to extracting meaningful diagnostic information from packet captures of VoIP calls.

## When you need a capture (and when you don't)

Not every call quality problem requires a packet capture. If calls are [choppy during afternoon hours](/blog/afternoon-call-quality) and your bandwidth monitoring shows the internet link saturating at 3pm every day, you have your answer without opening Wireshark. If [phones are not ringing](/blog/phones-not-ringing) and the SIP registration status shows unregistered, start with the registration problem.

Packet captures become necessary when:

**The symptoms do not match an obvious cause.** One-way audio, intermittent drops, or [choppy audio](/blog/choppy-robotic-audio) with no apparent network congestion all warrant a closer look at what the packets are actually doing.

**You need to prove where a problem is occurring.** If your VoIP provider says the issue is on your network and you say the issue is on theirs, a capture at your network edge showing clean outbound packets and damaged inbound packets is strong evidence. Be precise about what it proves: the capture localizes the impairment to somewhere upstream of your capture point, which rules out your LAN; it does not by itself identify whose upstream network is at fault.

**SIP behavior is unexpected.** Calls failing for unclear reasons, [unexpected response codes](/blog/common-sip-problems), or features not working as configured all benefit from seeing the actual SIP messages exchanged.

## Where to capture

Placement matters. A capture taken at the wrong point in the network path may not contain the information you need.

**At the endpoint.** Some VoIP phones and softphones can generate their own packet captures. This is ideal because it shows exactly what the phone sends and receives, including any issues introduced by the local network. Polycom, Yealink, and most enterprise phones have a built-in pcap feature accessible through their web interface.

**At the switch (mirror port).** If the endpoint cannot capture, configure a SPAN or mirror port on your [managed switch](/blog/office-network-switches) to copy traffic from the phone's port to a monitoring port where your laptop runs Wireshark. This captures everything the phone sends and receives without affecting the phone's performance.

**At the router or firewall.** Captures here show traffic as it enters and leaves your network. This is useful for proving whether packets are clean when they leave your LAN (evidence that any remaining impairment lies beyond your edge, on the ISP, transit, or far-end side), but you miss issues that occur between the phone and the router.

**On both sides.** For the most complete picture, capture simultaneously at the endpoint and at the network edge. Comparing the two captures shows you exactly where packets are being lost, delayed, or reordered.

## SIP analysis: the call setup story

Before you look at audio quality, check that the call set up correctly. Open the capture in Wireshark and use the **Telephony → SIP Flows** or **Telephony → VoIP Calls** dialog to see a visual call flow diagram.

What to look for:

**The INVITE and its response.** A healthy call starts with an INVITE, receives a 100 Trying, then a 180 Ringing, then a 200 OK, and the caller sends an ACK. If you are seeing [unusual response codes](/blog/sip-response-codes), the [SIP message anatomy](/blog/anatomy-of-a-sip-message) and the response code tell you what went wrong and at which point in the dialog.

**SDP content.** The [SDP bodies in the INVITE and 200 OK](/blog/sdp-media-negotiation) tell you what codec was negotiated, what IP addresses and ports are being used for media, and whether both sides agree on the media parameters. Mismatches here cause [one-way audio](/blog/one-way-audio) and codec problems. Check that the IP addresses in the SDP are routable and correct; [NAT issues](/blog/sip-nat-traversal) often manifest as private IP addresses appearing in SDP where public addresses should be.

**Re-INVITEs.** Mid-call re-INVITEs can change codec, put calls on hold, or trigger other changes. An unexpected re-INVITE or a rejected re-INVITE can explain sudden quality changes or call drops.

**BYE timing.** If calls are [dropping after a set time](/blog/calls-dropping-after-set-time), look at what sends the BYE and when. A BYE from the far end's proxy after exactly 30 or 60 minutes often indicates a session timer. A BYE that does not appear at all (the call just stops) suggests a network interruption.

For a deeper walkthrough of SIP message analysis, see [reading a SIP trace](/blog/reading-a-sip-trace) and [first call flow: INVITE to BYE](/blog/first-call-flow-invite-to-bye).

## RTP analysis: the audio quality evidence

This is where packet captures earn their keep for quality troubleshooting. The RTP stream is the actual audio, and its characteristics tell you exactly what the listener experienced.

In Wireshark, go to **Telephony → RTP → RTP Streams** to see all RTP streams in the capture. Select a stream and click **Analyze** to get the detailed statistics.

### Packet loss

Wireshark calculates packet loss by looking at RTP sequence numbers. Each RTP packet has a sequential number. If sequence number 1000 is followed by 1002, packet 1001 was lost. Wireshark reports both the total lost packets and the loss percentage.

What the loss pattern tells you:

**Uniform, steady loss** (roughly the same percentage throughout the call) suggests a consistent network problem. A congested link, a misconfigured QoS policy, or a path with consistent errors.

**Burst loss** (periods of no loss punctuated by clusters of consecutive lost packets) points to momentary congestion events. A large file transfer or backup saturating the link for a few seconds, a routing reconvergence, or a buffer overflow on an intermediate device.

**Loss in one direction only** indicates an asymmetric problem. The path from A to B is fine but the path from B to A is impaired. This is common when the two directions of a call take different network paths, which is normal on the internet.

As a rough guide, loss above about 1% is often audible, calls become noticeably [degraded](/blog/understanding-voip-packet-loss) around 3-5%, and at 10% or more they are usually unusable. Treat these as operating guideposts rather than fixed thresholds: the audible impact depends on the codec, its packet loss concealment and FEC, the packetization interval, and whether the loss is random or bursty.

### Jitter

Wireshark calculates inter-arrival jitter for each RTP stream using the running statistical estimate defined in RFC 3550: a smoothed measure of the variation in the time between consecutive packet arrivals compared to the expected interval, not a direct per-packet delay reading.

For a standard 20ms ptime (packet time), packets should arrive roughly every 20 milliseconds. Wireshark graphs the actual arrival intervals so you can see where jitter spikes occur.

[Jitter](/blog/what-is-jitter-and-why-it-matters) that stays under 20-30ms is generally handled by the phone's jitter buffer without audible impact, and spikes above 50ms start to exceed typical buffer configurations, but these are typical operating figures, not universal thresholds. What actually matters is the endpoint's buffer depth and adaptation behavior: jitter becomes audible when the buffer either discards late packets (creating loss) or grows to introduce additional [delay](/blog/latency-jitter-packet-loss-details).

The jitter graph over time is more useful than the average jitter number. A call with 8ms average jitter sounds clean. A call with 8ms average jitter that includes two 200ms spikes does not, even though the average looks fine.

### Timing gaps

Look for gaps in the RTP stream: periods where no packets arrived. A gap of several hundred milliseconds or longer in the middle of active speech suggests a network interruption, a device failure, or a routing change. These gaps are distinct from silence suppression, where the sender intentionally stops sending packets during silence. Silence suppression gaps happen between speech bursts. Network gaps happen during speech.

Wireshark marks gaps in the RTP stream analysis. Correlate gap timing with any SIP signaling events (re-INVITEs, UPDATE messages) to determine whether the gap was intentional or a network problem.

### Payload type consistency

Each RTP packet carries a payload type number that identifies the codec. For G.711 u-law, this is payload type 0. For G.711 a-law, it is 8. For dynamic codecs like Opus, the payload type is assigned during [SDP negotiation](/blog/sdp-media-negotiation).

If the payload type changes mid-stream without a corresponding re-INVITE and new SDP negotiation, something is wrong. A [codec mismatch](/blog/how-data-moves-in-packets) mid-call causes the receiver to try to decode audio with the wrong codec, producing noise or silence.

## Common patterns and what they mean

**Clean SIP, bad RTP.** The call set up perfectly but the audio is terrible. This is a network quality problem, not a VoIP configuration problem. Focus on the RTP stream analysis to quantify the loss, jitter, and timing issues, then trace the network path to find the impaired segment.

**Packets fine at the switch, damaged at the router.** Comparing captures from two points shows packets being lost between them. You have an internal network issue: possibly a [misconfigured QoS policy](/blog/office-network-qos), an overloaded uplink, or a failing cable.

**Packets fine leaving your network, damaged on return.** The outbound RTP stream is clean in your capture but the inbound stream shows loss and jitter. The impairment is somewhere upstream of your capture point (your ISP, a transit network, or the far end), and the capture proves it is not your LAN, though it cannot say which upstream segment is responsible. This is where you take the evidence to your ISP or VoIP provider and ask them to investigate their side.

**Consistent ~30-second call drops.** The capture tells you which of two classic causes you have. If you see the 200 OK being retransmitted and no ACK arriving, the answering side never received the ACK, usually a [NAT or ALG](/blog/sip-nat-traversal) mangling the signaling path. Per [RFC 3261](https://www.rfc-editor.org/rfc/rfc3261.html) section 13.3.1.4, the answering UAS core keeps retransmitting the 2xx until an ACK arrives or 64×T1 elapses, which is 32 seconds at the default T1 of 500 ms; if no ACK ever arrives it gives up and considers the session terminated. (This is a UAS *core* behaviour, not Timer H; Timer H is the separate timer that governs a non-2xx INVITE server transaction.) If the signaling completes cleanly and RTP simply stops with no BYE, suspect a NAT or firewall state table timeout: the stateful device stops seeing traffic for long enough that it drops the session, and subsequent packets are blocked. Fixed-sounding timers like this need packet evidence, not guesswork.

**One-way audio from the start.** SDP analysis usually reveals the cause immediately: a private IP address where a public one should be, a port that is unreachable, or a [SIP ALG](/blog/sip-nat-traversal) rewriting the SDP incorrectly.

## Practical tips

**Filter early.** A busy network generates enormous captures. Use Wireshark display filters to focus on the call you care about. Filter by the phone's IP address (`ip.addr == 10.0.1.50`) or by SIP (`sip`) and RTP (`rtp`) protocols to cut the noise.

**Capture in both directions.** RTP is bidirectional. The caller sends a stream and receives a stream. Analyze both. A problem that only affects one direction tells you something different than a problem that affects both.

**Save the capture.** Pcap files are small relative to their diagnostic value. Save them with a naming convention that includes the date, the affected extension, and a brief description of the symptom. When you need to compare today's problem to last month's problem, you will be glad you kept the files.

**Correlate with call quality reports.** If your VoIP platform provides call quality metrics (jitter, loss, MOS estimates), compare them to what the packet capture shows. Discrepancies between platform-reported metrics and pcap-observed metrics tell you something about where the platform is measuring and what it might be missing.

Packet captures are not the first troubleshooting step and they should not be the last resort either. They sit in the middle of a competent troubleshooting process: after you have ruled out the obvious, before you start guessing. When the question is "what is actually happening on the wire," a pcap is the definitive answer. If you have a capture file and want a quick summary, the [PCAP analyzer](/tools/pcap-analyzer) extracts SIP signaling and RTP quality metrics directly in the browser.

---

## Call Recording Laws by State: What Your Business Needs to Know

URL: https://voiptest.com/blog/call-recording-laws-by-state
Published: 2026-05-15
Category: Industry
Tags: call-recording, compliance, legal, voip-security, business-voip, regulations

> **This article is for general informational purposes only and does not constitute legal advice.** Recording laws change frequently and vary by jurisdiction. We make no guarantees about the accuracy or completeness of this information. Always consult with your business attorney before implementing any call recording practices.

If your business records phone calls, you are subject to a patchwork of federal and state laws that determine when recording is legal and what happens when you get it wrong. The penalties range from civil lawsuits to criminal charges, depending on the state. This is not an area where "we didn't know" works as a defense.

The challenge for VoIP deployments is that recording is often a platform feature that can be enabled with a checkbox. The technology makes it trivially easy. The legal landscape makes it anything but.

## Federal law: the baseline

The federal Wiretap Act (18 U.S.C. § 2511) establishes the floor. Under federal law, recording a phone call requires the consent of at least one party to the conversation. If you are a participant in the call and you consent to the recording, that is generally sufficient under federal law. You do not need to tell the other person.

This is called one-party consent. It means that as long as one person on the call knows it is being recorded, the recording is generally legal at the federal level, with one carve-out worth knowing: under 18 U.S.C. § 2511(2)(d), one-party consent does not protect an interception made for the purpose of committing a criminal or tortious act.

But federal law is just the minimum. States are free to impose stricter requirements, and several do.

## One-party consent states

The majority of states follow the federal one-party consent standard. In these states, you can legally record a call you are a party to without informing the other person. This covers most business use cases where an employee records their own calls.

One-party consent does not mean you can record calls you are not a party to. Intercepting and recording a conversation between two other people without any of their knowledge is illegal everywhere. The "one party" who consents must be a participant in the call.

For business purposes in one-party states, the main practical question is whether your employees count as the consenting party when the company's system automatically records their calls. Generally, yes, if the employee knows and agrees that calls are being recorded. The employee's consent satisfies the one-party requirement.

## Two-party consent states

These states require that all parties to the call consent to the recording before it begins. "Two-party" is the common shorthand, but the actual requirement in most of these states is all-party consent. If there are five people on a conference call, all five need to know.

Two caveats before the list. First, it is dated: this reflects the statutes as of this article's last update (August 2026), and recording law changes; treat any undated state list, including a stale copy of this one, with suspicion. Second, the one-party/all-party binary is a simplification. Statutes differ on which media they cover, whether the conversation must be confidential or private, whether violations are criminal or civil, and what exceptions apply; and some states (Oregon, which applies different rules to in-person versus telephone conversations, and Nevada, where court interpretation of the phone-recording statute diverges from its one-party text, among others) do not fit cleanly in either column.

**California.** California Penal Code § 632 requires consent from all parties for recording confidential communications. The key word is "confidential": conversations where a party has an objectively reasonable expectation that the conversation is not being overheard or recorded. Business calls generally qualify as confidential.

**Connecticut.** The classic example of a state that resists the binary. Its criminal eavesdropping law is narrower, but C.G.S. § 52-570d creates civil liability for recording telephone conversations without the consent of all parties, subject to statutory exceptions, including verbal or written notification and an automatic tone warning. Connecticut is sometimes overlooked on these lists, but the civil exposure is real and has been consistently enforced.

**Florida.** Florida Statute § 934.03 requires all-party consent. Florida courts have been active in enforcing this, and the statute provides for civil damages and criminal penalties.

**Illinois.** The Illinois Eavesdropping Act (720 ILCS 5/14) has a complicated history. The original all-party consent law was struck down as unconstitutional in 2014, and the legislature passed a revised version that reinstated all-party consent with narrower scope. The current law prohibits recording private conversations without consent of all parties.

**Maryland.** Maryland Courts and Judicial Proceedings § 10-402 requires all-party consent. Maryland courts have interpreted this broadly.

**Massachusetts.** M.G.L. c. 272, § 99 is one of the strictest recording laws in the country. It requires all-party consent and has been interpreted to apply even when the recording party is a participant in the conversation. The statute's language around "secret" recording has been the basis for numerous prosecutions.

**Montana.** Montana Code § 45-8-213 prohibits recording without consent of all parties. Montana's statute is less frequently litigated than California's or Massachusetts', but the requirement is clear.

**New Hampshire.** RSA 570-A:2 requires all-party consent for recording telephone communications. New Hampshire's statute applies specifically to telecommunications and has limited exceptions.

**Pennsylvania.** 18 Pa.C.S. § 5703 requires all-party consent. Pennsylvania is notable because its statute has been enforced aggressively, including in cases where one party recorded a call they were participating in without telling the other party.

**Washington.** RCW 9.73.030 requires all-party consent. Washington's law extends to in-person conversations as well and has been broadly interpreted by state courts.

## The interstate problem

This is where it gets complicated for VoIP specifically. Phone calls cross state lines routinely. If you are in Texas (one-party consent) and you call someone in California (all-party consent), which law applies?

There is no clear federal rule that resolves this conflict. Courts have gone different directions depending on the jurisdiction, the specific facts, and which state's law the plaintiff chose to invoke. Some courts apply the law of the state where the recording was made. Others apply the law of the state where the recorded party was located. Some have applied the stricter standard.

For businesses, the practical answer is straightforward even if the legal answer is not: **follow the stricter standard.** If there is any chance the other party is in a two-party consent state, treat it as a two-party consent call. The cost of adding a recording disclosure is near zero. The cost of getting it wrong can be substantial.

This is especially relevant for businesses with customers or clients in multiple states. If you are a call center, an MSP handling support calls, or any business that regularly calls across state lines, the safest approach is to treat every call as if two-party consent applies.

## What this means for VoIP platforms

Modern VoIP and UCaaS platforms make call recording a feature, not a project. That is both a convenience and a risk. The same checkbox that enables recording for legitimate quality assurance also creates a potential legal liability if consent requirements are not met.

### Automatic vs on-demand recording

Platforms typically offer two modes. Automatic recording captures every call without any per-call action. On-demand recording lets a user press a button to start recording mid-call.

Automatic recording is the most legally exposed mode. Every call is recorded whether or not the appropriate consent was obtained. If your platform records every call and you do not have a disclosure playing at the start of each one, you are creating a recording of every call that arguably violates two-party consent laws when the other party is in an all-party state.

On-demand recording gives you more control but creates its own problems. The user needs to know when they need consent, and they need to actually get it before pressing the button. Training and compliance procedures become critical.

### Recording announcements

The standard mitigation is a pre-call announcement: "This call may be recorded for quality assurance purposes." Played at the start of every call, this disclosure puts the other party on notice. Courts in many jurisdictions have treated continuing the call after a clear announcement as implied consent, but that is a risk control with a strong track record, not a universal rule. Whether implied consent is legally sufficient depends on the jurisdiction and the facts, and some states specify the form consent must take.

The details matter. The announcement should be clear and audible. It should play before any substantive conversation begins. It should be present on every call, not just calls your agent initiates (inbound calls need it too). Some organizations use a beep tone at regular intervals during recording, though this is not a legal requirement in most states.

### Encryption and storage

Recording consent is not the only legal consideration. How you store and secure recordings matters too. Recorded calls often contain sensitive information: account numbers, health information, financial details. [Encrypting the media stream](/blog/how-srtp-works) protects the call in transit, but you also need to think about encryption at rest for stored recordings, access controls, and retention policies.

The [regulatory landscape](/blog/msp-regulatory-landscape) for VoIP extends well beyond recording consent. If your business handles calls subject to HIPAA, PCI-DSS, or other compliance frameworks, the recording storage requirements layer on top of the consent requirements.

## Best practices

**Default to disclosure.** Play a recording announcement on every recorded call. This is the simplest way to reduce consent risk across jurisdictions, even though it is not a guarantee of sufficiency in every one.

**Document your policy.** Have a written call recording policy that specifies which calls are recorded, why, how recordings are stored, who has access, and how long they are retained. Train your employees on it.

**Know where your callers are.** If you have a [STIR/SHAKEN](/blog/msp-stir-shaken) implementation or caller ID data, you may be able to identify the geographic origin of calls. But do not rely on this for legal compliance. Area codes do not reliably indicate a caller's physical location.

**Configure your platform correctly.** Work with your VoIP provider to ensure recording announcements play at the right time, that recordings are [properly secured](/blog/sip-authentication-security), and that on-demand recording workflows include consent prompts.

**Audit regularly.** Recording features can be enabled accidentally, policies can drift, and new employees may not receive proper training. Regular audits of your recording configuration and compliance procedures catch problems before they become legal exposure.

**When in doubt, ask your attorney.** This area of law is genuinely complicated, it varies by state, and it changes. A business attorney familiar with telecommunications law in your operating states is the right resource for specific guidance. This article gives you the framework to ask informed questions. It does not replace legal counsel.

---

## Why Fax, Fire Alarms, and Elevators Resist VoIP

URL: https://voiptest.com/blog/analog-holdouts
Published: 2026-05-14
Category: Fundamentals
Tags: voip-fundamentals, analog, fire-alarm, security, fax, migration

Every VoIP migration hits the same wall. You have moved the phones, the users are happy, the old PBX is unplugged, and then someone asks about the fax machine. And the fire alarm panel. And the elevator phone. And the security system. And the postage meter in the mailroom that apparently has a phone line plugged into the back of it.

These are the analog holdouts. They are devices that were designed for a dedicated, always-on, copper-pair analog phone line, and they resist conversion to VoIP for reasons that range from "annoying but solvable" to "governed by life-safety codes that dictate exactly what may replace the line." Understanding why each one is difficult, and how difficult, saves you from learning the hard way that your fire alarm has been offline for three months.

## Why analog devices are different from phones

A VoIP phone is designed to work on a data network. It speaks SIP, it handles [codec negotiation](/blog/sdp-media-negotiation), it tolerates reasonable amounts of [jitter and packet loss](/blog/latency-jitter-packet-loss-details), and it recovers gracefully from brief network interruptions. It was built for this environment.

Analog devices were built for a completely different environment. A traditional analog phone line (POTS, Plain Old Telephone Service) provides:

**A dedicated circuit.** When the device goes off-hook, it gets a circuit with guaranteed bandwidth and zero contention. No other traffic competes with it. No congestion, no packet loss, no jitter. The connection is either there or it is not.

**Line power.** The phone company provides 48 volts DC on the copper pair. The device draws power from the line itself. No external power supply needed. No UPS. No network switch. If the building loses power, the analog line still works because the central office has its own battery plant and generator.

**Simplicity.** The signaling is electrical. On-hook, off-hook, dial tone, DTMF tones, ring voltage. No software stack, no firmware updates, no network configuration. The device has worked the same way for decades.

VoIP eliminates all three of these. The circuit is replaced by a shared data network. The line power is replaced by a dependency on your network infrastructure (switches, routers, internet connection) plus external power. The simplicity is replaced by a stack of protocols and a dependency on multiple systems being functional simultaneously.

For a phone on someone's desk, these tradeoffs are fine. For a device that calls the fire department when your building is on fire, they are not.

## Fire alarm panels

This is the one that can actually get someone hurt, so it deserves the most attention.

Fire alarm communicators dial out to a central monitoring station when an alarm triggers. The traditional setup is two dedicated POTS lines (a primary and a backup) connected to the fire alarm control panel (FACP). The panel seizes the line, dials the monitoring station, and transmits alarm data using a protocol like Contact ID or SIA. The monitoring station acknowledges receipt. If the primary line fails, the panel uses the backup line. The panel also regularly tests the lines by placing supervision calls to verify they are working.

The reason this is hard to convert to VoIP:

**Reliability requirements.** NFPA 72 (the National Fire Alarm and Signaling Code) specifies how alarm signals must be transmitted and the acceptable failure modes. A POTS line either works or it does not, and the panel can detect a failed line almost immediately by checking for dial tone. A VoIP connection can fail in partial, ambiguous ways: the network is up but the SIP registration has lapsed, the internet is up but the trunk provider is having an outage, the ATA has power but its firmware crashed. The fire panel has no way to know that the VoIP path behind the ATA is broken.

**Power independence.** A POTS line works when the building power is out. A VoIP path requires your network switch, your router, your internet connection, and your VoIP provider to all be functioning. Even with a UPS on every piece of equipment, you have multiplied the points of failure. If the UPS runs out before power is restored, the alarm communicator goes silent, and nobody knows.

**Code compliance.** Your local Authority Having Jurisdiction (AHJ), the fire marshal or building inspector, has to approve the alarm communicator arrangement. Many AHJs have historically required POTS lines and are cautious about approving alternatives. This is changing, but it varies enormously by jurisdiction.

**A generic ATA is not the answer.** The issue is not that IP transmission is categorically prohibited (NFPA 72 recognizes multiple transmission technologies); it is that the code requires the communication path to be a listed arrangement with supervision and fault reporting, backup power, and transmission-time performance, all approved by the AHJ. A consumer ATA on the office VoIP system is not listed for fire alarm service, cannot report the failure of the network behind it to the panel, introduces latency and potential packet loss into a signaling protocol designed for a clean circuit, and does nothing to address the power dependency problem. Whether any particular arrangement complies is ultimately the AHJ's call, and a generic ATA is not going to get that approval.

### What actually works

The industry has moved toward two alternatives:

**Cellular communicators.** A cellular module (often called an alarm communicator or radio) is installed in or next to the fire panel. It communicates with the monitoring station over the cellular network, bypassing both POTS and VoIP entirely. These are UL-listed for fire alarm use, have their own battery backup, and are increasingly accepted by AHJs. Most major alarm monitoring companies now support cellular communicators. This is the most common replacement for POTS lines on fire panels today.

**IP communicators.** UL-listed IP alarm communicators connect the fire panel to the monitoring station over an IP network. These are not ATAs. They are purpose-built devices designed to meet fire alarm communication standards, with their own supervision mechanisms, acknowledgment protocols, and fallback paths. They typically require a dedicated, monitored network connection and may require a cellular backup path. AHJ acceptance varies.

The key point is that both of these are engineered solutions with their own listing and certification. They are not "plug the fire panel into the VoIP system." If you are migrating a building off POTS, the fire alarm communicator needs its own conversation with the alarm company and the AHJ, separate from the phone system migration.

## Elevator phones

Building codes (ASME A17.1 for elevators, IBC for the building) require a phone in the elevator cab that connects to a location where someone can dispatch help. The requirements typically include:

- The phone must work without user action beyond lifting the handset (or in some cases, just pressing a single button)
- The call must connect to a live person or a monitoring service, not to a voicemail box or auto-attendant
- The phone must work during a power outage (elevators have battery lowering, and the phone needs to work after the cab reaches a floor)
- The connection must be reliable enough that a person trapped in an elevator can get help

A POTS line inherently meets all of these. A generic ATA on the building's VoIP system does not, for the same reasons as fire alarms: power dependency, multiple points of failure, and the inability of a simple analog device to detect that the VoIP path behind the ATA is broken. That is not the same as saying IP or cellular paths are prohibited (recent editions of ASME A17.1 accommodate two-way communication over alternative means), but the arrangement must satisfy the code's power, monitoring, and reliability requirements and be accepted by your inspector, which a bare ATA will not.

The trapped-in-an-elevator scenario is worth thinking through. The building lost power. The elevator stopped between floors. The emergency generator (if there is one) is running the elevator controller to bring the cab to a floor, but the passenger does not know that. They pick up the elevator phone. If that phone is connected through an ATA that is plugged into a network switch that lost power when the building did, there is no dial tone. The passenger is stuck in a dark elevator with a dead phone.

### What actually works

**Cellular lines.** Same concept as fire alarms. A cellular device in the elevator machine room provides a phone connection independent of the building's data network and power. This is the most common POTS replacement for elevator phones. The device has its own battery and its own cellular connection.

**Managed elevator phone services.** Some companies provide a complete elevator phone solution: hardware, cellular connectivity, monitoring, and testing. They handle the compliance requirements and provide documentation for your building inspector.

As with fire alarms, the answer is not "plug it into the VoIP system." It is a separate, purpose-built solution.

## Security and burglar alarm systems

Security alarm panels work similarly to fire panels. They have one or two phone lines, they dial a central monitoring station when an alarm triggers, and they periodically test the lines. The reliability requirements are less stringent than fire alarms (NFPA 72 applies to fire, UL 681 applies to burglar alarms), but the basic problem is the same.

The consequences of failure are different. A fire alarm communication failure can be a life-safety issue. A security alarm communication failure means a break-in might not be reported. Still serious, but the regulatory framework is less rigid.

Many security alarm companies have already migrated their customers to cellular or IP communicators, driven partly by [the ongoing retirement of copper POTS infrastructure by the phone companies](/blog/pots-copper-shutdown-2026). If your alarm system is still on POTS lines, your alarm company almost certainly has a cellular upgrade path. It is often a straightforward swap.

One thing to watch for: some alarm panels use the phone line not just for alarm communication but also for remote programming and firmware updates by the alarm company. If you remove the POTS line, confirm with the alarm company that they can still service the panel remotely via whatever replaces it, or that they are willing to do on-site service visits instead.

## Fax machines

Fax over VoIP is covered in detail in [Fax Over IP: Why Faxing Over VoIP Is Unreliable and What to Do About It](/blog/fax-over-ip), but the short version is: fax machines send data as precisely timed audio tones over a connection they expect to be clean and consistent. VoIP introduces [codec compression](/blog/sdp-media-negotiation), [jitter](/blog/what-is-jitter-and-why-it-matters), [packet loss](/blog/understanding-voip-packet-loss), and echo cancellation that can corrupt or destroy those tones.

Fax is the most solvable of the analog holdouts because the alternatives are mature:

**T.38 fax relay.** If both your VoIP system and your trunk provider support T.38, the fax tones are decoded into data at the sending end and reconstructed at the receiving end, eliminating sensitivity to the VoIP path. This works well when both sides support it. When only one side does, it can fail silently.

**Fax-to-email services.** Move faxing off the phone system entirely. Inbound faxes arrive as email attachments. Outbound faxes are sent via a web interface or email. No fax machine, no analog line, no ATA. This is the most reliable option for most businesses.

**Dedicated analog line.** Keep a single POTS line (or an ATA on a high-quality trunk) for the fax machine. Inelegant but effective. As POTS lines become harder to get and more expensive, this is a less viable long-term option.

Unlike fire and elevator lines, fax does not have a code compliance dimension. It is purely a reliability question. If faxing is critical to the business (medical offices, legal firms, government), invest in a solution that works rather than hoping G.711 passthrough will be reliable enough.

## Postage meters and other oddities

Postage meters phone home to download postage. Credit card terminals (the older dial-up kind) call a processor to authorize transactions. Some building management systems use analog lines for remote monitoring. Older medical devices report results over phone lines.

These devices generally have the same problem at a smaller scale: they were designed for a clean analog circuit and they make assumptions about timing, tone signaling, and connection reliability that VoIP does not guarantee.

For most of these, an ATA is an acceptable solution because the stakes are lower. If a postage meter fails to download postage, you try again. If a credit card terminal times out, you run the card again. Annoying, but not a safety issue. Set the ATA to use G.711 with no compression, disable echo cancellation on that port, and test thoroughly before considering the migration complete.

That said, many of these devices now have IP-native or cellular alternatives. Modern credit card terminals use IP or cellular. Postage meters increasingly connect over the network. When a device is up for replacement, replacing it with one that does not need an analog line at all is better than maintaining an ATA indefinitely.

## The migration checklist

Before you cancel the POTS lines in any building, walk the building and inventory every device connected to a phone line. Check:

- **Fire alarm panel**: How does it communicate? How many lines? Who is the monitoring company? What does the AHJ require?
- **Elevator phone**: What are the local code requirements? Who monitors the elevator phone line?
- **Security panel**: How many lines? Who is the monitoring company? Do they offer cellular?
- **Fax machines**: How many, and how critical? Can users switch to fax-to-email?
- **Everything else**: Postage meters, credit card terminals, building automation, medical devices, gate access systems, weather monitoring equipment, anything with an RJ11 jack

For each device, the question is not "can we make this work on VoIP?" It is "what is the right replacement path for this specific device?" Sometimes the answer is an ATA. Sometimes it is a cellular communicator. Sometimes it is replacing the device with an IP-native version. And sometimes, particularly during a transition period, the answer is keeping a POTS line or two until the rest of the migration is complete.

The worst outcome is discovering six months later that the fire alarm has not been communicating with the monitoring station since you pulled the copper. Inventory first, plan second, migrate third.

*For more on fax-specific issues and solutions, see [Fax Over IP: Why Faxing Over VoIP Is Unreliable and What to Do About It](/blog/fax-over-ip). For the broader context of VoIP migration planning, see [the MSP's Guide to VoIP](/blog/msp-should-you-offer-voice) series.*

---

## Lines Don't Exist Anymore: How VoIP Changes the Phone System Mental Model

URL: https://voiptest.com/blog/voip-lines-dont-exist
Published: 2026-05-13
Category: Fundamentals
Tags: voip-fundamentals, traditional-telephony, sip, migration

If you have been around phone systems long enough to remember key systems and multi-line phones, VoIP can be disorienting. The vocabulary is familiar but the underlying reality has changed completely. People talk about "lines" and "trunks" and "extensions," and while those words still get used, they do not mean what they used to mean. The mental model that made perfect sense for traditional telephony actively misleads you when applied to VoIP.

The single biggest conceptual shift is this: physical lines do not exist anymore. Understanding what replaced them clears up most of the confusion.

## What a line actually was

In traditional telephony, a line was a physical thing. It was a pair of copper wires running from the telephone company's central office to your building. Each line could carry exactly one phone call at a time. If you wanted to make or receive two simultaneous calls, you needed two lines. Ten simultaneous calls, ten lines. This was not a configuration choice. It was physics.

A small office might have had four lines. A larger office might have had a PRI (Primary Rate Interface), which was a digital circuit that carried 23 voice channels on a single physical connection. Each of those 23 channels was still, conceptually, a line: one call per channel.

The phone on your desk reflected this reality. A multi-line phone had physical buttons, one per line. Line 1, line 2, line 3. When a call came in on line 2, the light next to the line 2 button flashed. You pressed the button to pick up that specific line. If all your lines were in use, the next caller got a busy signal. There was nothing abstract about this. You could count lines, you could see them in use, and you could run out of them.

Key systems, the phone systems common in small and mid-size offices from the 1970s through the 2000s, were built entirely around this model. Every line from the phone company appeared on every phone (or at least on a set of phones). Users manually selected which line to use for outgoing calls. The key system's job was to make the lines available to the phones and provide basic features like intercom and hold. The lines themselves were the phone company's responsibility.

## What replaced lines

VoIP eliminated the physical line entirely. There is no pair of copper wires. There is no dedicated circuit. A [VoIP phone](/blog/what-is-voip) connects to your network, registers with a SIP server, and sends and receives calls as data packets. The phone's connection to the server is a [SIP registration](/blog/sip-registration), and a single network connection can handle multiple simultaneous calls.

The concept of a "line" got replaced by several different things, depending on which aspect of the original you are talking about:

**The physical connection** was replaced by the network. Your phone connects to an Ethernet port (or WiFi), gets an IP address, and registers to the phone system over the data network. One network connection can carry as many concurrent calls as your bandwidth, trunk contract, and endpoint configuration allow; the wire itself is no longer the constraint.

**The trunk to the phone company** was replaced by [SIP trunks](/blog/sip-trunking). A SIP trunk is a logical connection between your phone system and your trunk provider. Unlike a PRI with its fixed 23 channels, a SIP trunk's capacity is defined by your contract and your [bandwidth](/blog/why-speed-tests-cant-measure-voip), not by the physical infrastructure. You might buy capacity for 20 concurrent calls or 200. If you need more, you change the contract, you do not install new hardware.

**The line appearance on the phone** survived as a user interface element. Your VoIP phone might still have buttons labeled line 1, line 2, line 3. But those buttons represent call appearances: separate call sessions you can manage on that phone. They have no connection to a physical circuit. You can configure a phone to have two call appearances or six. It is a software setting, not a wiring decision.

**The phone number** was decoupled from everything. In traditional telephony, a phone number was tied to a physical line, which was tied to a physical location. In VoIP, a phone number is just a routing rule. It can point to a single phone, a group of phones, an auto-attendant, a voicemail box, or a complex call flow that tries multiple destinations in sequence. The number has no physical attachment to anything.

## Where the old mental model misleads you

### "We need more lines"

In the traditional model, running out of lines was a real, physical constraint that required ordering more service from the phone company. In VoIP, the equivalent constraint is concurrent call capacity on your SIP trunk, and it is usually not the bottleneck people think it is.

A G.711 call uses about 87 Kbps of bandwidth in each direction (a representative figure for 20ms packets on Ethernet; the exact number varies with headers and encapsulation). A typical business internet connection can support dozens or hundreds of concurrent calls from a pure bandwidth perspective. The actual limits are your SIP trunk contract (how many concurrent calls you are paying for), your [internet upload bandwidth](/blog/internal-vs-external-calls), and your [network's ability to prioritize voice traffic](/blog/office-network-qos).

When someone says "we need more lines," what they usually mean is one of: we are running out of concurrent call capacity (a trunk configuration issue), we need more phone numbers (a DID provisioning issue), or the phones are not ringing when they should (a call routing issue). The solution to each of these is different, and none of them involves installing physical lines.

### "Which line is the call on?"

In a key system, this was a meaningful question. The call was literally on line 3, and you pressed the line 3 button to pick it up. In a VoIP system, calls are not "on" a line. They arrive at the system, the system routes them according to its configuration (ring groups, hunt groups, auto-attendant menus), and they appear on whichever phone or phones the system decides should ring.

If a receptionist needs to transfer a call to someone, they do not tell them "it's on line 2." They transfer it. The call appears on the destination phone as a new incoming call. The concept of a shared line where multiple people can see and pick up the same call still exists in VoIP; it is called a shared line appearance (SLA) or shared call appearance (SCA), but it is a feature you configure, not the default model.

### "The line is busy"

Traditional busy signals happened because a physical line was occupied. In VoIP, a phone can handle multiple simultaneous calls (limited by its call appearances), and the system can ring multiple phones for the same number. A "busy" condition in VoIP is usually a deliberate configuration choice: the phone is set to allow only one call, or call waiting is disabled, or a call queue is full. It is rarely a capacity constraint.

When a caller does get a busy signal or goes straight to voicemail, the question is not "are all the lines busy?" It is "how is the inbound routing configured, and why did the system decide not to ring a phone?"

### "We have a four-line phone system"

This used to mean four physical lines from the phone company, supporting four concurrent external calls. In VoIP, the equivalent statement is meaningless without more context. Do you mean four concurrent SIP trunk channels? Four phone numbers? Four phones? Four call appearances per phone? The number four is no longer tied to a physical reality that constrains everything else.

## What you actually need to think about instead

With the line abstraction gone, the things that matter in a VoIP system are:

**Concurrent call capacity.** How many simultaneous calls can your system handle? This is determined by your SIP trunk provider contract, your internet bandwidth (particularly [upload](/blog/why-speed-tests-cant-measure-voip)), and your system's processing capacity. For a hosted PBX, the provider handles the system capacity. For an on-premises system, you might have hardware or licensing limits.

**DIDs (Direct Inward Dialing numbers).** These are your phone numbers. You can have as many as you need, and they are not tied to physical lines. If you are unsure what carrier a number is currently on or whether it is wireline or wireless, a [carrier lookup](/tools/carrier-lookup) will tell you. A 10-person office might have 10 DIDs (one per person), or 15 (personal numbers plus department numbers), or 3 (a main number, a fax number, and a support number). The count depends on your routing needs, not your wiring.

**Call routing.** This is the logic that replaced the line-to-phone mapping. When a call comes in to a specific DID, what happens? Does it ring one phone, a group of phones, or an auto-attendant? If nobody answers, does it go to voicemail, overflow to another group, or forward to a mobile phone? This is all configured in software and can be as simple or complex as you need.

**Call appearances per phone.** This is the vestige of the old line button model. How many simultaneous calls can a user manage on their handset? Two is typical for a regular user. Six or more for a receptionist who juggles multiple callers. This is a per-phone setting.

**Registration and presence.** In VoIP, the system knows which phones are online, which are on a call, and which are available. This is automatic. You do not need to look at blinking lights on a key system to know which lines are in use. The system tracks it and can make routing decisions based on it. [BLF (Busy Lamp Field)](/blog/sip-call-features) keys on phones can show you the status of other extensions, replacing the visual line-in-use indicators of the key system era.

## The exceptions: where lines, channels, and ports still exist

It is worth noting that some businesses still have actual analog lines, usually for specific purposes. Elevator phones, alarm systems, fax machines, and emergency phones in stairwells sometimes still run on traditional copper pairs from the phone company, or on analog ports from an ATA (Analog Telephone Adapter) connected to the VoIP system.

If your building has an older alarm system or elevator phone that requires an analog line, those still behave exactly like traditional lines. One call, one line, copper wires. The same is true of each FXS port on an ATA or analog gateway: a port carries exactly one call at a time, so counting ports is still real capacity planning wherever analog devices survive. They are increasingly being replaced by cellular connections or VoIP adapters, but they persist in enough places that you will encounter them.

Channel counting has not disappeared elsewhere either. A SIP trunk's concurrent-call limit is a hard ceiling that behaves operationally much like a channel count: the 21st simultaneous call on a 20-channel trunk fails or overflows, just as it would have on a full PRI. And any gateway that bridges VoIP to a PRI or analog trunks inherits the fixed channel count of the circuit behind it. The abstraction changed from wiring to contract and configuration, but the arithmetic still matters when you size a system.

## Why this matters for troubleshooting

When users describe phone problems using the old line-based vocabulary, you need to translate. "Line 2 isn't working" might mean a specific call appearance is misconfigured, a specific DID is not routing correctly, or the second concurrent call on a SIP trunk is failing. "All the lines are busy" might mean the SIP trunk concurrent call limit has been reached, or the ring group is configured to stop ringing after a certain number of calls, or there is a [registration issue](/blog/sip-registration) preventing phones from receiving calls.

The troubleshooting approach changes completely. Instead of checking physical wiring and line cards, you are checking SIP registrations, call routing rules, trunk capacity, and network health. The tools are different, the diagnostics are different, and the solutions are different. But the vocabulary persists, and knowing how to translate between the old model and the new one saves a lot of confusion.

*For more on how SIP registration connects phones to the system, see [SIP Registration: How Your Phone Tells the World Where It Is](/blog/sip-registration). For the fundamentals of how SIP trunks replaced traditional phone lines to the outside world, see [SIP Trunking: Connecting to the Outside World](/blog/sip-trunking). For call features like BLF, shared line appearances, and parking that replaced the key system model, see [SIP Call Features](/blog/sip-call-features).*

---

## VoIP Trunk Capacity: What You Can Actually Verify

URL: https://voiptest.com/blog/voip-overbooking
Published: 2026-05-12
Category: Fundamentals
Tags: sip-trunking, voip-fundamentals, quality, troubleshooting, capacity

Shared capacity is how almost every network service is built. ISPs do not provision every subscriber's advertised speed simultaneously. Airlines and hotels sell against expected no-shows. The underlying principle is statistical multiplexing: when you can characterize aggregate demand, you can serve it with less capacity than the sum of the individual maximums, and everyone pays less as a result.

VoIP trunk providers work the same way, and there is nothing improper about it; it is ordinary traffic engineering, formalized in standards like [ITU-T E.600](https://www.itu.int/rec/T-REC-E.600/en). What matters is not whether capacity is shared but **what the provider has committed to deliver when demand peaks, and what you can actually verify from outside their network.**

The honest answer to that second part is: less than you would like. This article covers how the capacity is structured, what peak-hour symptoms do and do not establish, and which contract terms are worth pinning down, because those terms, not inference from symptoms, are what you can hold a provider to.

## How trunk capacity is structured

A [SIP trunk](/blog/sip-trunking) provider has a finite amount of infrastructure: session border controllers (SBCs) that handle signaling and media, bandwidth at peering points where their network connects to upstream carriers, and capacity on those upstream carriers for terminating calls to the PSTN.

When a provider sells you 50 concurrent call channels, they are making a commitment that your system can have up to 50 simultaneous calls transiting their network. The question is whether they have provisioned enough infrastructure to honor that commitment to every customer at the same time.

As an illustration of the arithmetic: a provider with 1,000 customers who each bought 50 channels has sold 50,000 channels of concurrent entitlement. Building for 50,000 simultaneous calls would be enormously expensive and the pricing would reflect it. Instead the provider characterizes its aggregate traffic (suppose the observed peak across all customers is nearer 15,000 concurrent calls) and engineers to that observed demand plus headroom, against whatever blocking objective it has set itself.

The relationship between sold entitlement and engineered capacity is sometimes described as an overbooking ratio, and it is worth being clear about what you can know here: **you cannot.** Providers do not publish these figures, you cannot derive one from symptoms on your own trunks, and you cannot infer one from price or from how many channels a provider is willing to sell you. Any specific ratio you see quoted (including in this article, where the numbers above exist only to show the shape of the calculation) is illustrative rather than measured industry data. The only sources for a real figure are a contractual commitment, the provider's own disclosure, or a measurement set someone will stand behind.

## What price differences actually reflect

Per-channel pricing between providers can vary by 3x or more for what looks like the same service, and it is tempting to read that gap as a proxy for engineering headroom. It is not a reliable one.

Price reflects termination costs and which interconnects a provider has, the product tier you are being quoted, the support model, contract length and volume commitments, how much of the stack the provider owns versus resells, and the margin and market position it has chosen. Engineering headroom is one input among many, and it is not separable from the others when all you can see is a number on a quote.

There are real differences between providers in how much they invest per customer: direct interconnects with major carriers instead of routing through aggregators, redundant SBCs, staff to notice a capacity problem before customers do. Those differences tend to cost money, so they push price up. But the inference does not run backwards: a cheaper quote does not establish thinner engineering, and a more expensive one does not establish the opposite. What you can do is make the provider state its commitments, which is what the questions later in this article are for.

## How it works at a technical level

Capacity is finite at every layer of the provider's infrastructure, and a constraint at any one of them can surface as a quality problem on your calls.

**SBC session limits.** The SBC is the front door. It handles SIP signaling (call setup, teardown, authentication) and often proxies or relays media. Each SBC has a maximum number of concurrent sessions it can handle, determined by CPU, memory, and licensing. When an SBC hits its session limit, new calls get rejected, typically with a SIP 503 (Service Unavailable) response. Be careful reading that code in the other direction, though: RFC 3261 defines 503 only as the server being temporarily unable to process the request, and maintenance windows, routing policy, and upstream carrier failures produce exactly the same response. A 503 is consistent with overload; it is not proof of overbooking. A well-run provider distributes load across multiple SBCs, but the aggregate capacity of their SBC farm is still finite.

**Media processing.** If the provider performs any media manipulation (transcoding between codecs, recording, SRTP-to-RTP conversion), that consumes CPU. Media processing is far more resource-intensive than signaling. A system that can handle 10,000 signaling sessions might only be able to transcode 2,000 simultaneous calls.

**Bandwidth at peering points.** Where the provider's network connects to other networks (upstream carriers, internet exchanges, other providers), there is a fixed amount of bandwidth. Each G.711 call consumes <a href="https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/7934-bwidth-consume.html" rel="nofollow noopener noreferrer" target="_blank">80 kbps in each direction at the IP layer</a>, or 87.2 kbps once Ethernet framing is counted at 20 ms packetization; for trunk and peering sizing the IP figure is the relevant one. At 10,000 concurrent calls, that is around 800 Mbps of media traffic in each direction. If the peering link is saturated, packets queue up and get delayed or dropped. The symptoms are jitter and packet loss: the classic markers of degraded call quality.

**Upstream carrier capacity.** The trunk provider is often not the one actually connecting your call to the PSTN. They buy termination from upstream carriers, who have their own capacity limits and their own engineering assumptions, invisible to both you and, beyond contractual commitments, often to your provider as well. A call that traverses two or three constrained networks can accumulate degradation at each hop, which is also why localizing a problem to one operator is genuinely hard rather than merely inconvenient.

## What happens when a capacity limit is reached

The failure modes depend on which resource is exhausted first.

**Failed call setups.** When SBC capacity or upstream carrier capacity is exhausted, new calls simply fail. Your PBX sends an INVITE and receives a 503 response, or worse, the INVITE times out with no response at all. The user hears silence, then eventually a fast busy or an error tone. If your PBX is configured with failover to a secondary trunk, it may retry on another provider, adding several seconds of [post-dial delay](/blog/afternoon-call-quality) but eventually completing the call.

**Increased latency.** When bandwidth at peering points is saturated, packets queue in buffers before being forwarded. This adds latency to every call transiting that link. Once one-way delay pushes past roughly 150 ms ([the commonly cited transmission-planning boundary from ITU-T G.114](https://www.itu.int/rec/T-REC-G.114/en), not a cliff where audio fails), conversation starts to feel awkward, with the actual effect depending on total mouth-to-ear delay and echo control. G.114 treats the whole 150 to 400 ms band as acceptable so long as planners understand the impact, and puts 400 ms as the ceiling for general network planning. Past that, holding a natural conversation becomes actively difficult because both parties talk over each other.

**Jitter.** Congestion does not add a constant amount of latency. It adds variable latency: some packets get through quickly, others wait in queues. This variation is jitter. The receiving end has a jitter buffer that absorbs some variation, but when jitter exceeds the buffer's capacity, packets arrive too late to be played and are effectively lost. The result is choppy, broken audio.

**Packet loss.** When buffers overflow, packets get dropped. How audible a given loss rate is depends on the codec, its concealment, and whether losses are random or come in bursts; congestion loss tends to be bursty, which conceals worse. As rough working figures for a narrowband codec without FEC: even <a href="https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_12_5/design/guide/html/index/Bandwidth-Latency-and-QoS-Considerations-for-Unified-CCX-for-Release-12-5-1.html" rel="nofollow noopener noreferrer" target="_blank">1-2% packet loss</a> is audible as clicks, gaps, or robotic-sounding audio; at 5%, conversation becomes difficult; at 10%, the call is essentially unusable. The [MOS score](/blog/understanding-mos-scores) drops rapidly with even small amounts of packet loss.

**Quality degradation without total failure.** This is the insidious case. The provider is not so overloaded that calls fail outright, but overloaded enough that every call is slightly worse than it should be. Estimated MOS drops from, say, 4.2 to 3.5. Users do not report it as a problem; they just perceive the phone system as "okay" rather than "good." Over time, this becomes the new normal, and nobody realizes the system should sound better than it does.

## Reading a peak-correlated pattern

The useful signal is predictability: problems that track someone else's aggregate traffic rather than your own. That is worth recognizing, so long as you are precise about the conclusion it supports.

Degradation correlated with business-hours peaks is evidence of a **time-correlated constraint somewhere on the path.** It does not identify which operator, and it does not establish that capacity was oversold rather than, say, a peak-hour routing change, an upstream carrier's congestion, a saturated peering link neither party owns, or a software limit that only bites under load. Overbooking is one hypothesis on that list. Confirming it takes provider-side utilization, admission-control and interconnect telemetry, which is a request you make, not a measurement you can take.

With that established, the patterns worth looking for:

**Time-of-day patterns.** Quality degrades during peak business hours, typically 9 AM to 12 PM and 1 PM to 4 PM in the provider's primary time zone. If you are in a different time zone than most of the provider's customer base, you might experience peak congestion at unusual times relative to your own business hours. Calls at 7 AM or after 6 PM sound noticeably better.

**Day-of-week patterns.** Weekdays are worse than weekends. Monday mornings and Friday afternoons may be particularly bad because of higher-than-average call volumes across the provider's customer base.

**Monthly patterns.** Some businesses see spikes at month-end (collections, billing, sales closing). If your provider serves a lot of customers in industries with month-end surges, you might see degradation during the last few days of every month even if your own volume is flat.

**The on-net vs off-net test.** This is the most diagnostic check you can run, as long as you read it for what it actually shows. During a period when you suspect quality degradation, make an [on-net call](/blog/internal-vs-external-calls) (internal extension to extension, not traversing the trunk) and an off-net call (through the trunk to the PSTN) at the same time. If on-net sounds perfect and off-net sounds degraded, the problem is not your local network. What the test does not do is pinpoint who: beyond your PBX, the path includes your ISP, intermediate peering, the trunk provider, its upstream carriers, the PSTN interconnect, and the far end's network. It moves the fault boundary outside your building; what starts to implicate the trunk provider specifically is degradation that correlates with aggregate business-hours peaks rather than with your own traffic or your ISP's known congestion.

**Intermittent problems the provider cannot reproduce.** You open a ticket. The provider investigates during off-peak hours, finds nothing wrong, and closes it. You experience the problem again the next morning. This cycle repeats. If the provider's investigation never happens during the exact times you experience the issue, they will never see the congestion because it only exists during peak load.

## Concurrent call limits: contract vs reality

Your contract might say 50 concurrent channels. But that number can mean different things depending on how the provider structures their service.

**Hard limits.** Some providers enforce a strict session limit at the SBC. Call 51 gets rejected. You always get your 50, and the 503 is your signal to add capacity. This is clean and predictable.

**Soft limits.** Other providers allow bursting above your contracted limit. You bought 50 channels but can actually use 60 or 70 during a burst. This sounds generous until you realize the burst capacity is shared. When the provider's overall network is not busy, everyone can burst. When the network is congested, burst capacity disappears and you are back to your contracted limit, or worse, you cannot even reach your contracted limit because the shared infrastructure is overwhelmed.

**Committed vs burst capacity.** Some providers make this explicit. They sell "up to 100 channels" with a "committed" rate of 50. The committed rate is what they guarantee; the burst rate is best-effort. During off-peak you may get all 100. During peak you should expect the committed 50, and the question worth asking before you sign is what happens if even that is not available, because that is precisely what the blocking objective and the SLA remedy are for.

Read the contract carefully. "Up to" is doing a lot of work in "up to 100 concurrent calls."

## Quality tiers and route selection

Not all calls follow the same path. Many providers maintain multiple route categories.

**Direct routes.** The provider has a direct interconnect with the terminating carrier. The call goes from your provider to the destination carrier with no intermediaries. Fewest hops, lowest latency, most predictable quality.

**Standard routes.** The call goes through one or two intermediate carriers. Quality is generally acceptable but less consistent than direct routes.

**Least-cost routes.** The provider uses a least-cost routing (LCR) engine that sends the call through whichever upstream carrier is cheapest at that moment. The path changes call by call. Quality varies because the cheapest route is not always the best route. Some LCR providers dynamically reroute calls through lower-quality carriers during peak periods because the higher-quality carriers are full or more expensive at that time.

Some providers sell these as explicit tiers. A "premium" trunk product uses direct routes and a "standard" product uses LCR. The premium product costs more but delivers consistently better quality. Others do not tell you which routing they use; they just sell you trunks and route your calls however is most profitable for them at that moment.

If your provider offers quality tiers, consider putting your highest-value traffic on the premium tier and your less critical traffic on standard. A sales floor where every call is a revenue opportunity warrants premium routing. An internal dial tone for a warehouse where people check voicemail twice a day does not.

## What to ask a prospective trunk provider

Before signing a trunk contract, ask these questions. The answers, and how the provider responds to being asked, tell you a lot.

**"How do you engineer capacity against sold entitlement, and what is your blocking objective at peak?"** Most providers will not give you a ratio, and that is fine; the ratio was never the useful artifact. What you are listening for is whether they can articulate a capacity management approach at all. "We monitor aggregate utilization and add capacity at 70% of observed peak, and we engineer to a stated blocking target" tells you something real about their operations. "We provision 100% of sold capacity at all times" is either a very expensive product or not accurate.

**"What is my concurrent call limit, and is it hard or soft?"** You need to know whether your limit is enforced at the SBC or is a contractual number that depends on shared infrastructure.

**"What routes will my calls take?"** Ask specifically about PSTN termination. Do they have direct interconnects with major carriers? Do they use LCR? Do they offer different quality tiers? A provider that cannot or will not describe their routing is a red flag.

**"Can you provide quality metrics for my calls?"** Providers who monitor quality and make metrics available to customers are more likely to be managing their network proactively. Providers who have no quality reporting are flying blind, or they have the data and do not want you to see it.

**"What happens during peak periods?"** Ask about their busiest times and what capacity management looks like during those periods. Ask for historical uptime and quality statistics if available.

**The terms to get in writing.** Everything above is conversation; these are what you can actually enforce. Committed concurrent sessions, as distinct from any "up to" figure. The blocking target at peak. How burst capacity is treated when the network is busy. What the SLA measures, where it measures it, and what remedy it provides when the measurement is missed. A provider that commits to these in writing has given you something to hold them to regardless of how they engineer behind it.

**Red flags:** Reluctance to discuss capacity or routing at all. No quality reporting or monitoring tools. Support reachable only by email. Contract terms that disclaim quality obligations entirely, or that quote only an "up to" channel count with no committed figure behind it.

## When a budget provider is a reasonable choice

Not every business needs a premium trunk. What matters is your call volume relative to the provider's peak load, and how much a bad hour costs you.

A five-person office making 20 calls a day, with maybe two or three calls concurrent at peak, is statistically invisible on the provider's network. They will almost never be the ones who get a 503 because they are using so little capacity. For this office, a budget provider is a rational choice. The savings are real and the risk is low.

A 100-seat call center running 60-80 concurrent calls during business hours is a completely different situation. They are a meaningful share of the provider's peak load. They will feel every capacity constraint. They need a provider whose infrastructure can handle their peak demand reliably, which means paying for that infrastructure. For this operation, saving $2 per channel per month by using a budget provider is a false economy when one bad hour costs more in lost productivity and lost deals than a year of the price difference.

The middle ground (a 20-50 person office with moderate call volume) is where the decision gets interesting. If the business is not particularly sensitive to voice quality (internal calls, low-stakes conversations), a mid-tier provider is fine. If voice is revenue-critical (sales teams, customer support, professional services where client perception matters), pay for quality.

Businesses in the middle ground are the ones most likely to suffer quietly, because they have enough volume to feel a constraint but not enough visibility into their own quality metrics to characterize it when it happens. They just know that "the phones sound bad sometimes" and attribute it to their internet connection or their PBX.

## Measure it, then ask

You cannot see inside a provider's network, but you can establish that a problem is real, when it happens, and that it is not yours, which is what turns a support ticket from an anecdote into something actionable.

Track [MOS scores](/blog/understanding-mos-scores) over time. Compare peak against off-peak. Run a [VoIP quality test](/tools/voip-test) during both to quantify the difference, and use the [bandwidth calculator](/tools/bandwidth-calculator) to confirm your own connection has headroom for your concurrent call volume. Run the [on-net vs off-net comparison](/blog/internal-vs-external-calls) during a suspect period to move the fault boundary outside your building.

What that gives you is a documented, time-correlated pattern with your own network ruled out. The next step is not a conclusion but a request: ask the provider for utilization and admission-control data covering the windows you measured, and for the interconnect the affected calls traversed. How they respond to a specific, evidenced request, and whether the terms you signed give you any remedy if the answer is unsatisfactory, is usually more informative than the data itself.

---

For more context on related topics, see our posts on [SIP trunking fundamentals](/blog/sip-trunking), [why call quality degrades in the afternoon](/blog/afternoon-call-quality), [capacity planning for MSPs](/blog/msp-capacity-planning), and [working effectively with trunk providers](/blog/msp-vendor-relationships). If you are evaluating a new provider, our guide to [trunk configuration](/blog/msp-trunk-configuration) covers the technical setup side.

---

## SIP and WebSockets: How Browser-Based VoIP Works

URL: https://voiptest.com/blog/sip-and-websockets
Published: 2026-05-11
Category: Fundamentals
Tags: sip, websockets, browser-voip, voip-fundamentals, softphones

If you've ever used a browser-based softphone, a click-to-call widget, or a web-based contact center agent interface, you've used SIP over WebSockets and the browser's real-time media stack together, whether you knew it or not. These two technologies solve complementary halves of the same problem: how do you make a real phone call from inside a web browser?

The answer is more interesting than you might expect, because browsers were never designed for real-time communications. Every piece of this stack exists because of a specific constraint that browsers impose.

## The fundamental problem

[SIP](/blog/what-sip-actually-is) was designed for a world where endpoints could open UDP or TCP sockets on arbitrary ports. A SIP phone typically listens on UDP port 5060. It sends and receives SIP messages directly. It opens separate UDP ports for RTP media. This is fine for hardware phones and softphone applications running on a desktop operating system.

Browsers can't do any of that.

A web page running in Chrome or Firefox has no ability to open raw UDP or TCP sockets. It can make HTTP requests, open WebSocket connections, and use a handful of other browser APIs, but it cannot send a UDP packet to port 5060 on some SIP server. This is a security feature, not a bug. Letting arbitrary web pages open raw network sockets would be a catastrophe. But it means that traditional SIP transport (UDP, TCP, or TLS over TCP) is completely unavailable from a browser context.

So if you want SIP signaling in a browser, you need a transport that browsers actually support. That transport is WebSockets.

## SIP over WebSockets: RFC 7118

RFC 7118, published in 2014, defines how to carry SIP messages over WebSocket connections, registering two transports: plain WebSocket (`WS`) and secure WebSocket (`WSS`). The concept is straightforward: the browser opens a WebSocket connection (in practice almost always WSS, the TLS-encrypted variant) to a SIP server that supports WebSocket transport. Once the connection is established, standard SIP messages are sent and received as WebSocket text frames.

The SIP messages themselves are the same SIP messages you'd see on any other transport. A REGISTER is still a REGISTER. An [INVITE still contains SDP](/blog/sdp-media-negotiation). The [authentication challenges](/blog/sip-authentication-security) work the same way. The only difference is the transport layer carrying those messages.

A SIP message over WebSocket includes a Via header that indicates the transport:

```
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
```

That `WSS` tells every SIP entity in the path that this message arrived via a secure WebSocket connection. The domain in the Via header is typically a random identifier rather than a real hostname, since the browser doesn't have a routable address where it can receive inbound connections.

This is an important difference from traditional SIP. A desk phone has an IP address and a port. You can send it a SIP message at any time. A browser-based client is reachable only through its WebSocket connection to the server. The server acts as the anchor point, maintaining that persistent connection and routing messages to the browser through it.

## How the browser's media stack fits in

SIP over WebSockets solves the signaling problem, but signaling is only half of a phone call. The other half is the actual audio. You need a way to capture audio from the user's microphone, encode it, encrypt it, send it across the network in real time, receive audio from the other party, decode it, and play it through the speakers. All with latency low enough for a conversation to feel natural.

This is what the browser's real-time media stack does.

Every modern browser ships one: a standardized API and protocol suite for capturing, encoding, encrypting, and transporting live audio and video. When a browser-based softphone places a call, SIP over WebSockets handles the call setup and teardown, while that stack handles everything about the actual audio stream.

The two are connected through SDP. When the browser's SIP stack sends an INVITE, the SDP body is generated by the browser's media engine. That SDP contains the media parameters that engine will use: codecs, ICE candidates for [NAT traversal](/blog/sip-nat-traversal), DTLS fingerprints for encryption, and the ports where the browser wants to receive media.

Here's a simplified view of what the SDP in a browser-originated INVITE looks like:

```
v=0
o=- 4858522468 2 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE audio
m=audio 9 UDP/TLS/RTP/SAVPF 111 0 8
c=IN IP4 0.0.0.0
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=ice-ufrag:aR9l
a=ice-pwd:fE82jkS03bq1mMdoZ8Gy6f
a=fingerprint:sha-256 D1:2B:3C:...
a=setup:actpass
a=candidate:1 1 udp 2113937151 192.168.1.50 54321 typ host
a=candidate:2 1 udp 1845501695 203.0.113.50 62432 typ srflx raddr 192.168.1.50 rport 54321
```

A few things stand out compared to [traditional SIP SDP](/blog/sdp-media-negotiation). The media line specifies `UDP/TLS/RTP/SAVPF` rather than plain `RTP/AVP`, because browser media mandates encryption via DTLS-SRTP. The ICE candidates appear directly in the SDP (or are trickled in afterward). The `a=fingerprint` line provides the DTLS certificate fingerprint for end-to-end encryption verification. And the first codec listed is almost always Opus.

## How a browser-based call actually flows

Let's trace a complete call from a browser-based softphone to a traditional SIP desk phone. This involves several systems working together.

**1. WebSocket connection and registration**

When the web softphone loads, it opens a WSS connection to the SIP server (e.g., `wss://sip.example.com/ws`). Over this connection, it sends a SIP REGISTER to authenticate and announce its presence:

```
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/WSS j4k8s9d2f.invalid;branch=z9hG4bK74bf9
Contact: <sip:alice@j4k8s9d2f.invalid;transport=ws>
Authorization: Digest username="alice", ...
```

The server authenticates the request and responds with 200 OK. Alice's browser is now registered and can make and receive calls.

**2. The INVITE**

Alice clicks a button to call Bob. The browser's SIP library creates a peer connection, generates an SDP offer from the browser's media engine, wraps it in a SIP INVITE, and sends it over the WebSocket:

```
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/WSS j4k8s9d2f.invalid;branch=z9hG4bKnew1
Contact: <sip:alice@j4k8s9d2f.invalid;transport=ws>
Content-Type: application/sdp

[Browser-generated SDP with ICE candidates, DTLS fingerprint, Opus codec]
```

**3. The gateway problem**

If Bob is on a traditional desk phone, there's a mismatch. The browser is offering browser-style media (Opus, DTLS-SRTP, ICE), and Bob's phone expects traditional RTP (G.711, SRTP or plain RTP, no ICE). Something needs to bridge that gap.

This is where Session Border Controllers (SBCs) and browser-calling gateways come in. The SIP server or an SBC in the path terminates the browser media session on one side and establishes a traditional RTP session on the other. It transcodes Opus to G.711, terminates DTLS-SRTP and re-encrypts (or doesn't) as SRTP or plain RTP, and handles the ICE negotiation on the browser side while using a simple static media address toward the desk phone.

**4. Media flows**

Once the [call is established](/blog/first-call-flow-invite-to-bye) (200 OK, ACK), audio flows. On the browser side, the media stack handles everything: ICE connectivity checks complete, the DTLS handshake establishes encryption keys, and SRTP audio packets start flowing directly between the browser and the SBC or media gateway. On the desk phone side, standard RTP flows as it always has.

**5. Hangup**

Either side sends a BYE through the signaling path. The browser sends it over WebSocket, the desk phone sends it over UDP or TCP. The gateway handles the translation in both directions.

## Browser SIP stacks

You don't implement SIP over WebSockets from scratch. Several mature JavaScript libraries handle the SIP protocol and its integration with the browser's media stack:

**JsSIP** is one of the original browser SIP stacks, lightweight and focused on the core SIP functionality. It handles SIP message parsing, transaction management, dialog management, and media session integration. It's been around since the early days of browser calling and is well-understood.

**SIP.js** is a more actively maintained library with a cleaner API and better TypeScript support. It abstracts more of the complexity of coordinating SIP signaling with browser media, making it the more common choice for new projects.

Both libraries handle the same fundamental task: they manage the SIP state machine (registrations, sessions, subscriptions) and coordinate with the browser's media API to generate SDP, handle ICE candidates, and manage the media session lifecycle. They send and receive SIP messages over a WebSocket connection and translate between SIP session events and peer connection state.

There are also commercial SDKs from VoIP platform providers that wrap these open-source libraries with additional features like call queuing, presence, and analytics.

## Session Border Controllers and browser-calling gateways

In practice, browser-based SIP clients rarely talk directly to a traditional SIP PBX. There's usually a browser-aware component in the path, either a standalone browser-calling gateway or an SBC with browser support built in.

This component does several things:

- **Transport translation**: Converts between SIP over WebSocket and SIP over UDP/TCP/TLS for communication with traditional SIP infrastructure.
- **Media bridging**: Terminates browser media (ICE, DTLS-SRTP, Opus) on one side and establishes traditional RTP sessions on the other.
- **Codec transcoding**: Converts between Opus and G.711/G.729 when necessary.
- **ICE handling**: Participates in ICE negotiation with the browser, acting as the media endpoint that the browser's media engine connects to.

Major SBC vendors (AudioCodes, Oracle, Ribbon) all support browser endpoints now. Open-source options like Asterisk with its built-in browser support, or Kamailio with the WebSocket module, provide the same functionality. FreeSWITCH has supported browser media for years and is commonly deployed as a browser-calling gateway.

## NAT traversal: how browser calling changes everything

One of the most painful aspects of traditional SIP is [NAT traversal](/blog/sip-nat-traversal). SIP embeds IP addresses inside message bodies and headers, and NAT devices don't rewrite those embedded addresses, leading to one-way audio, registration failures, and hours of troubleshooting.

The browser stack sidesteps this problem almost entirely by building ICE (Interactive Connectivity Establishment) into the core protocol. ICE is mandatory there, not optional. Every browser media session uses it.

Here's how it works in the browser context:

1. The browser gathers its local network interface addresses (host candidates).
2. It queries a STUN server to discover its public-facing address (server-reflexive candidates).
3. If configured, it allocates a relay address on a TURN server (relay candidates).
4. All of these candidates are included in the SDP (or sent as trickle candidates).
5. Both sides perform connectivity checks by sending STUN binding requests on each candidate pair.
6. The pair that works best is selected for media.

Because ICE tests actual connectivity before sending media, it doesn't matter what NAT type is between the browser and the network. If direct connectivity works, ICE will find it. If it doesn't, ICE falls back to TURN relay. This is a fundamentally more robust approach than the traditional SIP methods of STUN-based address discovery or SIP ALGs, which guess at what might work based on incomplete information.

The result is that browser-based VoIP calls have far fewer NAT-related audio problems than traditional SIP deployments. The one common exception is corporate networks that block UDP entirely or restrict TURN traffic, which can prevent browser media from flowing at all.

## Quality considerations

RFC 7874 requires browser real-time audio endpoints to implement Opus along with G.711 (PCMU and PCMA); so Opus is mandatory to implement, not mandatory on every negotiated call, but browser-to-browser and browser-to-gateway calls almost always pick it. Opus operates at up to a 48 kHz sample rate and supports everything from narrowband to fullband audio. Compared to the G.711 (narrowband, 8 kHz, 64 kbps) that dominates traditional VoIP, Opus sounds dramatically better. It's also far more bandwidth-efficient, the same audio quality can be achieved at lower bitrates, and it adapts dynamically to network conditions by adjusting bitrate, frame size, and complexity in real time.

This adaptability is one of the browser stack's under-appreciated strengths. When network conditions degrade, the Opus encoder reduces its bitrate before packets start getting dropped. The stack also includes built-in bandwidth estimation (REMB or Transport-CC) that continuously measures the available network capacity and feeds that information back to the encoder.

That said, browser-based VoIP introduces its own quality variables. The browser shares the network stack with everything else the user is doing. Background tabs downloading files, OS updates, other applications competing for bandwidth, all of these affect the browser's media stream. And [WiFi](/blog/wired-vs-wifi-for-voip) adds latency and jitter that a wired desk phone on a properly configured VLAN would never see.

The codec advantage and the network disadvantage roughly cancel out for many deployments. Browser-based calls on a stable network sound better than desk phones. Browser-based calls on congested WiFi can sound worse.

## Where this is headed

The browser media stack has effectively won the browser and mobile client battle. Every major UCaaS and CCaaS platform (Webex, Zoom, RingCentral, Genesys, Five9) uses it for browser-based and increasingly for native desktop and mobile clients too. The traditional SIP desk phone isn't disappearing from conference rooms and front desks anytime soon, but new endpoints are overwhelmingly browser-based.

SIP over WebSockets remains the most common signaling mechanism for these browser clients, though some platforms have moved to proprietary signaling over REST or gRPC. The SIP/WS + browser media combination has the advantage of interoperability. A browser client using SIP.js talking to a FreeSWITCH server can interoperate with any SIP-compliant PBX, trunk provider, or carrier. Proprietary signaling locks you into a single platform.

The trend is clear: the browser is becoming the default softphone, and SIP over WebSockets is the bridge that connects it to the existing telephone network.

---

For the traditional SIP fundamentals that underpin browser-based VoIP, see [What SIP Actually Is](/blog/what-sip-actually-is) and [Your First Call Flow: INVITE to BYE](/blog/first-call-flow-invite-to-bye). For the NAT traversal problems that the browser's mandatory-ICE approach largely eliminates, see [NAT Traversal: Why SIP and NAT Don't Get Along](/blog/sip-nat-traversal). For more on how SDP and codec negotiation work, see [SDP and Media Negotiation](/blog/sdp-media-negotiation). And if you're running browser-based softphones on WiFi, [Wired vs. WiFi for VoIP](/blog/wired-vs-wifi-for-voip) covers the quality implications.

---

## What Actually Happens During a Number Port

URL: https://voiptest.com/blog/how-number-porting-works
Published: 2026-05-10
Category: Fundamentals
Tags: voip-fundamentals, number-porting, lnp, telecom, pstn

Phone number porting is one of those things that sounds like it should be simple. You are moving a number from one carrier to another. The number does not change. The person using it does not change. It is a database update. And yet porting is the single most common source of delays, failures, and outages during carrier migrations.

Understanding the mechanics behind porting (the actual process, the systems involved, the specific points where things break) is essential for anyone managing voice infrastructure. This post walks through the entire process, from the regulatory framework that makes porting possible to the network-level routing changes that happen at activation.

## Why porting exists

Phone number portability was not always a thing. Before 1996, your phone number belonged to your carrier. If you switched carriers, you got a new number. This created massive switching costs and effectively locked customers into their current provider.

The Telecommunications Act of 1996 changed that. It required local exchange carriers, to the extent technically feasible, to support [Local Number Portability (LNP)](https://uscode.house.gov/view.xhtml?req=granuleid%3AUSC-prelim-title47-section251&num=0&edition=prelim), meaning customers could keep their phone numbers when switching providers. (Wireless portability came later, through separate FCC rules.) The intent was straightforward: remove the number as a barrier to competition so carriers would have to compete on price and service quality instead.

The FCC implemented this mandate in phases. Wireline LNP went live in the late 1990s. Wireless LNP followed in 2003. Today, all carriers (wireline, wireless, VoIP, and cable) are required to support number portability.

## The players

A port involves several parties, and understanding their roles clarifies why the process works the way it does.

**The winning carrier** (also called the new provider or gaining carrier) is the carrier the customer is moving to. The winning carrier initiates the port request.

**The losing carrier** (also called the old provider or current carrier) is the carrier the customer is leaving. The losing carrier must validate and release the number.

**The NPAC** (Number Portability Administration Center) is the central clearinghouse that manages the master database of ported numbers. When a port is activated, the NPAC updates its records and distributes the routing information to all carriers. The NPAC is operated by [iconectiv (formerly Telcordia)](https://docs.fcc.gov/public/attachments/DA-23-940A1.pdf), which the FCC selected as Local Number Portability Administrator; the contract itself is held by the North American Portability Management (NAPM) industry consortium, with FCC oversight.

**The LSMS** (Local Service Management System) is a carrier's local copy of the NPAC data. Carriers can connect to the NPAC directly with their own LSMS or receive the data through a service bureau that operates one on their behalf; not every carrier runs its own. Either way, the LSMS receives updates from the NPAC and feeds the routing databases that call-processing switches query. This is the system that makes ported numbers actually work: without it, calls to ported numbers would still route to the old carrier.

## The process, step by step

### Step 1: Letter of Authorization (LOA)

The process starts when the customer signs a Letter of Authorization giving the winning carrier permission to port their number. The LOA includes the customer's name, the authorized numbers, the account number with the losing carrier, and the customer's signature.

The LOA is a legal document. It authorizes the winning carrier to act on the customer's behalf and tells the losing carrier that the port is legitimate. An incorrect or missing LOA is one of the top reasons ports fail.

### Step 2: Local Service Request (LSR)

The winning carrier submits an LSR to the losing carrier through a standardized electronic interface. The LSR contains the information from the LOA along with technical details about the port: which numbers are being ported, the desired port date, the winning carrier's routing information, and the customer's account information as it appears on the losing carrier's records.

That last part ("as it appears on the losing carrier's records") is critical. The name, address, and account number on the LSR must match the losing carrier's records exactly. Not approximately. Exactly. If the customer's name is "Robert Smith" in the losing carrier's system and the LSR says "Bob Smith," the port will be rejected.

### Step 3: Validation and FOC

The losing carrier validates the LSR against their records. If everything matches, they issue a Firm Order Commitment (FOC), which confirms the port and specifies the activation date and time window.

If the information does not match, the losing carrier issues a reject. The reject includes a reason code that tells the winning carrier what was wrong. Common reject reasons include name mismatch, address mismatch, account number mismatch, and unauthorized request (the number is not on the account specified in the LSR).

The winning carrier corrects the information and resubmits. Each rejection-and-resubmission cycle adds days to the process. This is why pre-verifying the customer's account information with a Customer Service Record (CSR) before submitting the port is so important.

### Step 4: Port activation

On the FOC date, during the agreed time window, the winning carrier activates the pending port in the NPAC. The winning carrier supplies the routing data, specifically, the Location Routing Number (LRN) of the switch that will now handle calls to the ported number, and the NPAC validates the subscription version and updates its master database. The NPAC distributes routing records; it does not invent them.

The NPAC then distributes this update to every connected LSMS. Once the LSMS updates propagate, calls to the ported number start routing to the winning carrier instead of the losing carrier.

The losing carrier simultaneously deactivates the number on their switch. The entire activation is supposed to happen in a coordinated window, but in practice the timing between these two events (the NPAC update propagating and the losing carrier deactivating) is where the gap problem lives, which we will get to shortly.

## Why ports take so long

There are two different clocks here, and conflating them is the source of most confusion about porting timelines.

The first is the **order-to-port interval**. For a simple wireline-to-wireline or intermodal request that is complete and accurate, carriers subject to the FCC's LNP rules must support [an interval of one business day](https://www.ecfr.gov/current/title-47/chapter-I/subchapter-B/part-52/subpart-C/section-52.35), unless the customer or the new provider asks for a longer one ([FCC 09-41](https://docs.fcc.gov/public/attachments/FCC-09-41A1.pdf); see also the [small-entity compliance guide, DA 10-814](https://docs.fcc.gov/public/attachments/DA-10-814A1.pdf)). Simple wireless-to-wireless ports commonly run on a shorter industry interval again.

The second is the **customer's total project**, which routinely takes longer, and not because the interval is being breached. The clock above starts from a valid, complete request. Everything before that point sits outside it: gathering the account details, validation against the losing carrier's billing records, rejections and resubmissions, and scheduling. A requested future due date, which most business migrations want so the cutover lands on a planned date, alters the interval by agreement rather than violating it. Non-simple and project ports follow different workflows entirely.

So "one business day" and "my port took a week" are usually both true, describing different things. When a port genuinely is being sat on, that is worth escalating, but the first question is always which of the two clocks is actually running.

The procedural delays are not technical. Updating a database record takes milliseconds. The delays are procedural and organizational. The losing carrier has to validate the request against their billing system. Their porting department processes requests in queue order. If there is a rejection, the resubmission goes back into the queue. Business day rules apply: weekends and holidays do not count.

Losing carriers also have limited economic incentive to expedite ports. Every day a customer remains on their service is another day of billing. The FCC has fined carriers for deliberately delaying ports (a practice called "port blocking"), but there is a difference between deliberate obstruction and simply not prioritizing porting operations with additional staff.

## Why ports fail

Understanding the common failure modes helps you avoid them.

**Name or address mismatch.** The most frequent cause of rejection. The customer tells you their name is "John's Auto Shop" but the losing carrier has the account under "John A. Smith dba John's Auto Shop." The LSR gets rejected. The fix is to obtain a CSR from the losing carrier before submitting the port so you have the exact account information as it appears in their system.

**BTN confusion.** A business account often has one Billing Telephone Number (BTN) and multiple working telephone numbers. The BTN is the master number on the account. If you submit a port for a working number but reference the wrong BTN, or if the losing carrier's system requires the port to reference the BTN specifically, the port gets rejected. This is particularly common with PRI circuits where 23 channels share a single BTN.

**Unauthorized requests.** The LOA is missing, incomplete, or signed by someone not authorized on the account. Some carriers require the LOA to be signed by the exact person listed as the authorized contact on the account.

**Partial ports.** Porting some numbers off an account while leaving others is called a partial port. Partial ports are more complex because the losing carrier has to restructure the remaining service. If the BTN is one of the numbers being ported, the losing carrier needs to assign a new BTN to the remaining lines before releasing the ported number. This adds steps and opportunities for things to go wrong.

**Wireless-to-wireline complications.** Porting a wireless number to a wireline or VoIP carrier (or vice versa) involves additional validation because the number is crossing service types. The wireless carrier's porting process and system may differ from the wireline process, and the intercarrier communication sometimes hits edge cases that same-type ports do not.

## Simple ports vs. complex ports

The industry distinguishes between simple and complex ports, and the distinction matters because it determines the timeline and process.

A **simple port** involves a single line with no complex features. One phone number, one carrier, no hunt groups, no ISDN PRIs, no special routing. The FCC's one-business-day order-to-port interval applies to simple wireline-to-wireline and intermodal requests that arrive complete and accurate, and only from that point, not from when you first asked.

A **complex port** involves any of the following: multiple numbers on a single request, numbers on a PRI or T1 circuit, toll-free numbers (which use a different portability system, the SMS/800 database), numbers with special features like hunt groups or remote call forwarding, or numbers where the losing carrier requires circuit disconnection coordination.

Complex ports do not have the same one-business-day mandate, but they are not unregulated either: the FCC's rules require non-simple wireline and intermodal ports to complete within four business days unless a longer period is requested. What stretches to one to four weeks in practice is the project around that interval: validation, rejections and resubmissions, and scheduling. An office with 50 numbers on two PRIs, a toll-free number, and a hunt group is going to take significantly longer than porting a single cell phone number.

## What happens at the network level

When a port activates, the actual call routing change is elegant in its simplicity.

Every phone number in the PSTN has a home switch: the switch where the number was originally provisioned. Before porting existed, calls were routed based on the NPA-NXX (area code and exchange) of the called number. Every NPA-NXX maps to a specific switch.

When a number is ported, the winning carrier associates a **Location Routing Number (LRN)** with it in the NPAC subscription record. The LRN is the 10-digit identifier of the winning carrier's switch (or routing point); it looks like a phone number but it is a routing address, not a dialable number.

When someone calls a ported number, a carrier in the call path performs an **LNP dip**: a database query against LNP routing data derived from the LSMS. The query returns the LRN for the called number, and the call is routed to the switch identified by the LRN instead of the switch implied by the NPA-NXX. The originating carrier may perform the dip, but responsibility follows the **N-1 model**: if no earlier carrier in the path has queried, the next-to-last (N-1) carrier before the terminating switch must do so. The call arrives at the winning carrier's switch, which maps the called number to the customer's actual service (their [SIP trunk](/blog/sip-trunking), their PBX extension, their VoIP endpoint).

For non-ported numbers, the dip returns no LRN, and the call routes normally based on NPA-NXX. For ported numbers, the LRN overrides the default routing.

The dip adds a small amount of latency to call setup, typically a few milliseconds. It is imperceptible to users.

## The gap problem

The port activation is not truly instantaneous. There is a window (usually measured in minutes but sometimes longer) where the routing is in transition. The NPAC has been updated, but not every carrier's LSMS has received the update yet. Or the LSMS has been updated but the losing carrier has not deactivated the number on their switch yet. Or the losing carrier deactivated before the NPAC update fully propagated.

During this window, calls to the ported number may fail, ring at the old carrier with no one to answer, or reach a "number not in service" recording. The window is usually brief, but it exists, and for businesses that depend on inbound calls, even a 15-minute gap can be a problem.

This is why port activations are typically scheduled during low-traffic hours, and why [go-live day planning](/blog/msp-go-live-day) is so important for business migrations. Knowing the activation window, having a plan for what happens during the gap, and communicating the timeline to the end users are all part of a clean migration.

Some carriers offer "flash cut" porting where they coordinate the activation tightly to minimize the gap. But even a flash cut is not zero downtime. If inbound call continuity is critical, having a temporary forwarding number or an announcement in place during the activation window is a reasonable precaution.

## Best practices for smooth ports

**Get the CSR first.** Before submitting any port request, obtain a Customer Service Record from the losing carrier. This gives you the exact account name, address, BTN, and list of working numbers as they appear in the carrier's system. A [carrier lookup](/tools/carrier-lookup) can also help you confirm the current carrier and line type before you start the process. Use this information verbatim on the LSR. This single step eliminates the majority of port rejections.

**Verify the LOA.** Make sure the LOA is signed by an authorized contact on the account, includes all numbers being ported, and has the correct account number. Some carriers have specific LOA format requirements; check before submitting.

**Time the port.** Schedule the port activation during a low-traffic period. For most businesses, early morning or after business hours works well. Avoid Fridays: if something goes wrong, you do not want to be troubleshooting a failed port over the weekend with carrier porting departments closed.

**Have temporary numbers ready.** For critical inbound lines, provision temporary numbers on the winning carrier and set up forwarding before the port. If the port is delayed or the gap window runs long, callers can still reach the business.

**Communicate the timeline.** Tell the end users exactly when the port is scheduled, that there may be a brief interruption, and what to do if they notice problems. Set expectations early so a five-minute gap does not become a panicked support call.

**Track the FOC.** Once you have an FOC date, confirm it with both carriers. If the FOC date slips, you need to know immediately so you can adjust your [migration plan](/blog/porting-numbers-office-move) and notify the client.

## Porting in the VoIP world

VoIP-to-VoIP ports are often faster than traditional wireline ports. There are a few reasons for this.

VoIP carriers tend to have more modern, more automated porting systems. Many of them use electronic LSR submission and automated validation, which reduces the human-in-the-loop delays that slow down legacy carrier ports. Some VoIP carriers can complete ports in hours rather than days.

VoIP carriers also do not have the physical infrastructure complications of wireline ports. There is no copper pair to disconnect, no circuit to restructure, no truck roll to coordinate. The port is purely a database and routing change, which is what porting should have always been.

That said, VoIP ports are not immune to the same failure modes. Name mismatches, LOA problems, and partial port complications still apply. And porting between a VoIP carrier and a traditional wireline or wireless carrier still involves the slower carrier's process as the bottleneck.

If you are managing carrier migrations and want to understand how your [vendor relationships](/blog/msp-vendor-relationships) affect the porting experience, the responsiveness of a carrier's porting department is one of the most practical indicators of their overall operational quality. Carriers that port quickly and cleanly tend to run clean operations in general.

## Related reading

For more on managing number ports during office relocations, see [Porting Numbers During an Office Move](/blog/porting-numbers-office-move). If you are planning a VoIP cutover, [Go-Live Day Planning](/blog/msp-go-live-day) covers the broader migration coordination, including how porting fits into the overall timeline. And for understanding the SIP infrastructure that ported numbers ultimately land on, see [SIP Trunking](/blog/sip-trunking).

---

## How SRTP Works: Encrypting the Actual Phone Call

URL: https://voiptest.com/blog/how-srtp-works
Published: 2026-05-09
Category: Fundamentals
Tags: sip, srtp, encryption, security, voip-fundamentals

RTP, the protocol that carries VoIP audio, is plaintext. Every packet contains a chunk of encoded audio, and anyone who can see those packets on the network can decode them into a listenable conversation. This isn't a theoretical risk. Tools like Wireshark can reconstruct a phone call from a packet capture in a few clicks. Any router, switch, or tap point between the two endpoints has access to the full conversation.

SRTP exists to fix this. It's defined in RFC 3711 and it does exactly what you'd expect: encrypts the audio payload of each RTP packet so that intercepting the packets gives you nothing useful.

But SRTP itself only handles the encryption and authentication of media packets. It doesn't solve the harder problem: how do both sides agree on the encryption keys in the first place? That key exchange problem is where the real complexity lives, and it's where most of the interoperability headaches come from.

## What SRTP adds to RTP

SRTP wraps around RTP without changing the fundamental packet structure. The RTP header stays in the clear (sequence numbers, timestamps, SSRC identifiers are still readable), but the payload, the actual audio data, gets encrypted. SRTP also appends an authentication tag to each packet.

This gives you three things that plain RTP doesn't have:

**Confidentiality.** The audio payload is encrypted with AES, typically AES-128 in counter mode. Anyone intercepting the packet gets the RTP headers (which tell you that a call is happening and how many packets are flowing) but not the audio content.

**Authentication.** The HMAC-SHA1 authentication tag covers both the header and the encrypted payload. If anyone modifies the packet in transit, the receiving side detects it and discards the packet. This prevents an attacker from injecting audio or modifying the stream.

**Replay protection.** SRTP maintains a replay list based on packet sequence numbers. If an attacker captures a packet and retransmits it later, the receiving side recognizes it as a duplicate and drops it.

The encryption uses a master key and a master salt to derive separate session keys for encryption and authentication. The key derivation function means that even if an attacker compromises one session key, they can't easily work backward to the master key or forward to future session keys.

## The key exchange problem

SRTP defines how to encrypt packets once both sides have a shared key. It says nothing about how both sides get that key. This is a deliberate design choice: it separates the media protection mechanism from the key management mechanism, allowing different key exchange approaches for different use cases.

Three approaches have emerged, each with different security properties and different deployment contexts.

## SDES: keys in the signaling

SDES (Session Description Protocol Security Descriptions, RFC 4568) is the simplest approach. The encryption key is carried directly in the [SDP](/blog/sdp-media-negotiation) that's exchanged during call setup. When an endpoint sends an INVITE with an SDP offer, it includes a `crypto` attribute containing the SRTP master key, encoded in base64:

```
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
  inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnsKMjI=
```

The `RTP/SAVP` profile in the media line indicates SRTP (as opposed to `RTP/AVP` for plain RTP). The `a=crypto` line specifies the cipher suite and the key material. The answering side picks a crypto suite from the offer and includes its own key in the SDP answer.

The security model here is straightforward: if the SIP signaling is protected, the keys are protected. If the signaling is not protected, anyone who can see the SIP messages can extract the SRTP keys and decrypt the media.

This is why SDES only makes sense when the signaling runs over TLS (or more precisely, when every hop in the signaling path uses TLS). If your [SIP INVITE](/blog/first-call-flow-invite-to-bye) travels over UDP in plaintext, the SRTP keys are right there in the SDP body for anyone to read. You'd have encrypted media with the keys published in the clear: security theater.

In practice, most business VoIP deployments use SDES. The SIP trunk from your PBX to your provider runs over TLS, the keys are exchanged in the encrypted signaling, and the media is encrypted with SRTP. It works, it's simple, and it's well supported. The trust model is that you trust each SIP proxy in the signaling path not to misuse the keys, which is a reasonable assumption when the signaling path is your PBX talking directly to your provider's SBC.

The weakness shows up when the signaling traverses multiple hops through proxies you don't control. Each proxy that handles the SIP messages has access to the SRTP keys. SDES provides encryption against passive eavesdropping on the media path, but it doesn't provide end-to-end encryption if the signaling intermediaries are untrusted.

## DTLS-SRTP: keys on the media path

DTLS-SRTP (RFC 5763/5764) takes a fundamentally different approach. Instead of carrying keys in the signaling, the two endpoints perform a DTLS handshake directly on the media path: the same UDP ports that will carry the RTP packets. DTLS is essentially TLS adapted for UDP (since the media path uses UDP, not TCP).

The handshake uses Diffie-Hellman key exchange to establish a shared secret, from which the SRTP master key is derived. The signaling (SDP) carries only a fingerprint of each endpoint's DTLS certificate, not the key material itself:

```
m=audio 49170 UDP/TLS/RTP/SAVPF 111
a=fingerprint:sha-256 4A:AD:B9:B1:3F:82:18:3B...
a=setup:actpass
```

This is a stronger security model than SDES because the key material itself never traverses the signaling path: passive interception of the SIP messages yields no keys. But it's not independent of the signaling. The certificate fingerprints in the SDP are what bind the DTLS handshake to the endpoints the signaling identified, and RFC 5763 requires that binding to be protected: the fingerprint must travel over authenticated signaling (SIP over TLS end to end, or another identity mechanism). An active attacker who can rewrite the SDP can substitute their own fingerprint and man-in-the-middle the handshake. When the fingerprint arrives intact, a mismatch between it and the certificate presented in the handshake tells the endpoint something is wrong, and the connection is refused.

Browser-based calling mandates DTLS-SRTP. There is no option to use unencrypted media in a browser call: every browser media connection goes through a DTLS handshake before any audio or video flows. This is one of the design decisions that makes browser calling fundamentally more secure than traditional SIP for media encryption. The browser enforces it; the application can't opt out.

The tradeoff is complexity. The DTLS handshake adds a round trip before media can flow, and both endpoints need to support the DTLS stack. In the browser this is built in, so developers don't think about it. For traditional SIP endpoints, DTLS-SRTP support is less universal than SDES support.

## ZRTP: Zimmermann's approach

ZRTP (RFC 6189) was designed by Phil Zimmermann (of PGP fame) and takes yet another approach to the key exchange problem. Like DTLS-SRTP, it performs key exchange on the media path itself using a Diffie-Hellman exchange. Its distinctive property is that man-in-the-middle detection doesn't rely on the SIP signaling at all: the Short Authentication String (SAS) gives the humans on the call a way to verify the exchange themselves. (DTLS-SRTP also detects a MITM when its fingerprint is properly authenticated; ZRTP's difference is that its check is independent of signaling integrity.)

During the ZRTP handshake, both endpoints compute a short string (typically four characters or two words) derived from the key exchange. The users are supposed to read this string to each other over the voice channel and verify that they match. If an attacker is performing a man-in-the-middle attack, they'd have separate key exchanges with each endpoint, and the SAS values would differ.

ZRTP also implements key continuity: it caches key material from previous calls between the same endpoints, so that subsequent calls can detect if the key exchange parameters change unexpectedly (which might indicate a new man-in-the-middle attack).

In practice, ZRTP is niche. The SAS verification step requires user participation, which makes it impractical for most business VoIP deployments. You're not going to ask call center agents to verify authentication strings on every call. ZRTP found a home in privacy-focused applications (Signal's voice calling was influenced by ZRTP's design principles), but it never achieved mainstream adoption in enterprise VoIP.

## Which approach is used where

The landscape is fairly predictable:

**Traditional business VoIP (SIP trunking, hosted PBX):** SDES with TLS on the signaling path. This is the default for most SIP trunk providers and most IP PBXes. It's well understood, widely supported, and provides adequate security when the signaling path is encrypted.

**Browser-based calling (softphones in a tab, UCaaS platforms):** DTLS-SRTP, mandatory. No negotiation, no fallback to unencrypted. This applies to any platform that runs its media path through the browser, including many modern UCaaS products.

**Privacy-focused applications:** ZRTP or ZRTP-inspired designs. Rare in enterprise deployments.

**Legacy or budget VoIP:** Plain RTP with no encryption at all. More common than it should be. We'll come back to this.

## Performance overhead

A persistent myth in VoIP operations is that SRTP adds meaningful overhead, enough to justify not enabling it. This is wrong.

AES-128 encryption of a single RTP packet takes microseconds on any hardware built in the last fifteen years. Modern CPUs have AES-NI instructions that make the encryption essentially free in terms of processing time. The HMAC-SHA1 authentication tag computation is similarly fast.

The per-packet overhead in terms of bytes is the authentication tag (typically 10 bytes with the 80-bit tag, or 4 bytes with the 32-bit tag) and potentially a few bytes for the MKI (Master Key Identifier) if key rotation is in use. On a G.711 packet carrying 160 bytes of audio, 10 extra bytes is a 6% increase in payload size. On an Opus packet the fixed tag is proportionally *larger*: Opus payloads (RFC 7587) are often a few dozen bytes at typical voice bitrates, so 10 bytes can be 20% or more of the payload. But in absolute terms it's still 10 bytes per packet, which is negligible against the link's total budget.

The DTLS handshake does add latency at call setup: one or two round trips before media can flow. In practice this adds tens of milliseconds to the time before first audio, which is not perceptible to users given that SIP call setup already involves multiple round trips of signaling.

There is no legitimate performance reason to skip SRTP in any modern deployment.

## Common problems caused by encryption mismatches

Encryption mismatches cause some of the most confusing troubleshooting scenarios in VoIP, particularly [one-way audio](/blog/one-way-audio) and no-audio conditions.

**One side expects SRTP, the other doesn't.** If one endpoint sends encrypted media and the other is expecting plain RTP, the receiving side gets packets it can't decode. The audio codec sees garbled input and either outputs silence or noise. The call appears to connect normally at the SIP level (the INVITE succeeds, a 200 OK comes back, media flows in both directions), but one or both sides can't hear anything. In a [SIP trace](/blog/reading-a-sip-trace), the clue is in the SDP: look for `RTP/SAVP` on one side and `RTP/AVP` on the other, or look for the presence of `a=crypto` lines on one side and their absence on the other.

**Mismatched cipher suites.** Both sides want SRTP but they don't support a common cipher suite. Most implementations support `AES_CM_128_HMAC_SHA1_80`, which is the mandatory-to-implement suite from RFC 3711, so this is rare. But it does happen with older or non-standard implementations.

**SRTP-to-SRTP through a non-SRTP intermediary.** An SBC or media proxy in the middle that doesn't support SRTP will strip the crypto attributes from the SDP or fail the call entirely. This shows up when migrating to encrypted trunks: the PBX and provider both support SRTP, but a middle box that nobody remembered about doesn't.

**Certificate fingerprint mismatches with DTLS-SRTP.** In browser-calling deployments, if the DTLS certificate fingerprint in the SDP doesn't match the certificate presented during the DTLS handshake, the handshake fails and no media flows. A TURN server is not the usual culprit: TURN (RFC 8656) relays the DTLS packets unchanged, so the endpoint certificates pass through intact. A mismatch points instead at something that terminates or rewrites the media or signaling: an SBC or media gateway re-originating DTLS with its own certificate without updating the SDP fingerprint, or signaling elements mangling the fingerprint attribute.

All of these problems share a characteristic: the SIP signaling looks normal. The call connects. The issue is entirely in the media plane, and you need to look at the SDP details and the actual media packets to diagnose it.

## Why some providers still don't encrypt media

Despite SRTP being well established and having negligible performance cost, there are still VoIP providers and enterprise deployments running plain RTP. The reasons are mostly inertial rather than technical.

**Legacy equipment.** Older SIP endpoints, gateways, and PBXes that predate widespread SRTP support are still in production. Upgrading firmware or replacing hardware costs money, and if the system works, there's organizational resistance to changing it.

**Interoperability caution.** Providers who serve a wide range of customers with diverse equipment may default to plain RTP because it's the lowest common denominator. Enabling SRTP by default risks breaking calls for customers whose equipment doesn't support it.

**"It's on our private network."** Some organizations argue that media encryption is unnecessary because the RTP traffic stays on their private LAN or a dedicated MPLS circuit. This ignores the reality that private networks get compromised, internal actors exist, and the perimeter between "private" and "public" is increasingly blurry.

This is changing. Regulatory pressure (particularly in healthcare and finance), the growth of remote work (where "private network" no longer describes the path between a softphone on a home network and the corporate PBX), and the general shift toward encrypting everything by default are all pushing the industry toward mandatory SRTP. The browser platform's decision to make encryption non-optional has normalized the expectation that voice traffic should be encrypted.

If you're evaluating a VoIP provider and they don't support SRTP, that's a red flag, not just for security, but as an indicator of how current their infrastructure is.

---

For more on how SIP [authentication and signaling security](/blog/sip-authentication-security) work (including TLS for the signaling path that SDES depends on), how [SDP negotiation](/blog/sdp-media-negotiation) handles the crypto attributes described in this post, and how to [read a SIP trace](/blog/reading-a-sip-trace) to spot encryption mismatches, see those posts. If you're troubleshooting a call that connects but has no audio, the [one-way audio](/blog/one-way-audio) guide covers the full range of causes, including encryption mismatches.

---

## Your POTS Lines Have a Deadline: What the 2026 Copper Shutdown Means

URL: https://voiptest.com/blog/pots-copper-shutdown-2026
Published: 2026-04-07
Category: Industry
Tags: pots, copper-retirement, analog, fire-alarm, migration, compliance, fax

For years, the advice on POTS lines was "you should probably migrate off copper eventually." Eventually is here. AT&T has announced that copper service discontinuance in selected areas begins in summer 2026, with a stated goal of retiring the majority of its copper footprint by the end of 2029; and the schedule is carrier- and wire-center-specific, with affected customers receiving location-specific notices. Verizon, Lumen, and other carriers have their own copper retirement programs at various stages. If you still have Plain Old Telephone Service lines anywhere in your organization, this is no longer a planning exercise. It is a deadline.

The phones themselves are probably fine. Most businesses migrated voice to VoIP years ago. The problem is everything else that is still plugged into a copper pair: fire alarm panels, elevator phones, security systems, fax machines, and the collection of legacy devices that nobody thought about because the POTS lines just quietly worked and the monthly bill was small enough to ignore.

That bill is not small anymore.

## The price signal you should not ignore

POTS line costs have been climbing steadily. Businesses that were paying $20-30 per line a few years ago are now seeing $80-150 or more. This is not accidental. Carriers are pricing copper to encourage migration. Maintaining aging copper plant is expensive, and carriers would rather invest in fiber and wireless infrastructure. Higher prices push remaining customers to move, which reduces the subscriber base that justifies keeping the copper network operational.

If you are still on POTS and you have not noticed the price increases, check your telecom invoices. The lines that were "cheap enough to keep" may now be the most expensive phone lines in your building.

The price increase is the warning shot. The copper retirement filing is the deadline.

## What is actually at risk

Your desk phones are almost certainly on VoIP already. The risk is the analog infrastructure that was never migrated because it was working fine and nobody had a reason to touch it.

### Fire alarm panels

This is the highest-stakes item. Fire alarm communicators dial out to a central monitoring station when an alarm triggers. Most installations use two dedicated POTS lines: a primary and a backup. The panel regularly tests these lines by placing supervision calls to verify they are functional.

When the copper is decommissioned, those lines go dead. The fire alarm will still trigger locally (the horns and strobes will still work), but the signal to the monitoring station will not go through. Nobody gets dispatched. The fire department does not get called automatically. What the panel itself reports depends on the panel and communicator: many will detect the loss of loop voltage and raise a trouble condition, but supervision behavior varies, and a decommissioned line can fail differently than a cut wire: do not assume the panel will warn you.

You cannot solve this with a generic ATA. Plugging the fire panel into an ordinary VoIP adapter does not meet NFPA 72 requirements for listed equipment, supervision, and backup power, and will not satisfy your AHJ (Authority Having Jurisdiction). That does not mean IP paths are categorically prohibited; UL-listed cellular and IP communicators (including listed dialer-capture modules) exist precisely for this transition, but the replacement path must be designed, listed, and approved for the application, not improvised. This is covered in detail in [Why Fax, Fire Alarms, and Elevators Resist VoIP](/blog/analog-holdouts).

**What to do:** Contact your alarm monitoring company now. Ask about cellular or UL-listed IP communicators. These are listed devices with their own battery backup and supervised connection, purpose-built for fire alarm communication. Most monitoring companies have been migrating customers to cellular for years and have a straightforward upgrade path. Coordinate the timeline with your AHJ: some jurisdictions require approval before changing the alarm communicator type.

Do not wait for the copper disconnection notice. The monitoring company and the AHJ both need lead time, and if everyone in your wire center waits until the last month, there will be a backlog.

### Elevator phones

Building codes require a phone in the elevator cab that works during power outages and connects to a live person without the passenger needing to dial a number. POTS lines meet this inherently. A generic ATA on ordinary VoIP service does not, for the same reasons as fire alarms: power dependency, multiple points of failure, and no way for the phone to know the path behind the ATA is broken. IP or cellular paths are acceptable when the solution is designed for the application and approved by the relevant authority.

The most common replacement is a cellular elevator phone line. These devices are independent of your building's network and power, with their own battery and cellular connection. Managed elevator phone services handle the hardware, connectivity, compliance documentation, and testing.

**What to do:** Contact your elevator maintenance company or a managed elevator phone service. Budget for the hardware and monthly cellular service. If your building has multiple elevators, all of them need to be converted.

### Security and burglar alarm systems

Security panels work similarly to fire panels: they dial a monitoring station over POTS lines. The consequences of failure are less severe (property loss vs. life safety), and the regulatory requirements are less stringent, but the migration path is the same.

Many security alarm companies have already been pushing cellular upgrades. If your security panel is still on copper, your alarm company almost certainly has a cellular communicator they can install. This is often the simplest migration of the bunch.

**What to do:** Call your security monitoring company. Ask if your panel is still on copper and what the cellular upgrade looks like. This is often a single service visit.

### Fax machines

Fax over POTS has been reliable for decades. Fax over VoIP is unreliable for reasons covered in [Fax Over IP: Why Faxing Over VoIP Is Unreliable and What to Do About It](/blog/fax-over-ip). But unlike fire alarms and elevator phones, fax has mature alternatives that do not require copper:

**Fax-to-email services** move faxing off the phone system entirely. Inbound faxes arrive as email attachments, outbound faxes are sent via a web interface. No fax machine, no phone line, no compatibility issues. For most businesses, this is the right answer.

**T.38 fax relay** handles fax over VoIP by converting the tones to data at each end. This works when both sides support T.38. It is more reliable than G.711 passthrough but still less reliable than POTS or fax-to-email.

**What to do:** Ask whether fax is actually still necessary for the business. If it is, evaluate fax-to-email services. If physical fax machines must stay, T.38 through your VoIP provider is the next best option.

### Everything else

Walk your buildings. Look for RJ11 jacks in unexpected places. Common discoveries:

- **Postage meters** that phone home to download postage (most modern meters connect via IP or cellular now)
- **Older credit card terminals** that dial out for authorization (modern terminals use IP or cellular)
- **Building management systems** with modem connections for remote monitoring
- **Gate and access control systems** with phone line connections
- **Weather monitoring equipment**, irrigation controllers, or other specialty devices

For most of these, an ATA is an acceptable temporary bridge while you source an IP-native or cellular replacement. The stakes are lower: a postage meter that fails to download postage is an inconvenience, not a safety issue.

## How to audit your POTS exposure

You need to know two things: which lines you have and what is connected to them.

### Step 1: Pull your telecom invoices

Get a complete list of every active POTS line billed to your organization. Include all locations. Check for lines that may be billed under a different account or bundled with other services. The billing records are the definitive source: people forget about lines, but the invoices do not.

### Step 2: Trace each line physically

For every line on the invoice, find where it terminates in the building. Follow the wire from the demarc to the device. Document what is connected. You will likely find lines you did not know about connected to devices nobody remembers installing.

### Step 3: Classify by migration path

For each device, determine the right replacement:

| Device | Migration path | Urgency |
|--------|---------------|---------|
| Fire alarm panel | Cellular communicator (coordinate with monitoring company + AHJ) | **High**: life safety, longest lead time |
| Elevator phone | Cellular elevator phone service | **High**: code compliance, needs building management coordination |
| Security panel | Cellular communicator (coordinate with monitoring company) | **Medium**: straightforward upgrade |
| Fax machine | Fax-to-email or T.38 | **Medium**: business impact varies |
| Everything else | ATA bridge or IP-native replacement | **Low**: evaluate case by case |

### Step 4: Check your carrier's timeline

Contact your carrier (or check their copper retirement notices) for your specific locations. The timeline varies by wire center. Some locations may have more time than others. Some may have less time than you expect.

Use our [carrier lookup tool](/tools/carrier-lookup) to verify the current carrier and line type for each number. If a line has already been ported or reclassified, that is information you need before planning the migration.

### Step 5: Schedule the work

Start with fire alarms and elevator phones. These have the longest lead times because they involve third parties (monitoring companies, AHJs, elevator contractors) and compliance requirements. Do not leave these for last.

## The timeline

If you are in one of the AT&T areas where discontinuance begins in summer 2026, you have weeks to months, not years. Watch for the location-specific notice. Even if your specific wire center is later in the schedule, the direction is clear: AT&T has said it intends to be off the majority of its copper footprint by the end of 2029, and copper is going away. Starting now means you migrate on your schedule. Waiting means you migrate on the carrier's schedule, possibly with less support and fewer options as demand for migration services spikes.

The POTS line that has been quietly working in the corner for fifteen years is about to stop working. Find it before it finds you.

*For the technical details on why specific analog devices resist VoIP conversion, see [Why Fax, Fire Alarms, and Elevators Resist VoIP](/blog/analog-holdouts). For fax-specific guidance, see [Fax Over IP: Why Faxing Over VoIP Is Unreliable and What to Do About It](/blog/fax-over-ip).*

---

## DNS and VoIP: SRV Records, NAPTR, and Why Phones Fail When DNS Does

URL: https://voiptest.com/blog/dns-and-voip
Published: 2026-03-28
Category: Fundamentals
Tags: voip-fundamentals, dns, sip, troubleshooting, network-architecture

DNS is one of those infrastructure components that nobody thinks about until it breaks. And when it breaks for VoIP, the symptoms are baffling. Phones that were working fine suddenly cannot register. Calls fail intermittently with no pattern you can see. Failover to a backup server does not happen even though you configured it. Half your phones work and half do not, on the same network, with the same configuration.

The reason DNS problems produce such strange VoIP symptoms is that VoIP depends on DNS in ways that are more complex than simple web browsing. A web browser looks up a hostname, gets an IP address, and connects. A SIP phone might perform a chain of three different DNS lookups before it knows where to send its first packet, and if any link in that chain is slow, stale, or wrong, the behavior can be unpredictable.

## The basics: A records and why they are not enough

At the simplest level, a VoIP phone needs to know the IP address of its SIP server. You configure the phone with a hostname like `sip.example.com`, the phone does a DNS A record lookup, gets back `203.0.113.10`, and sends its [REGISTER](/blog/sip-registration) request to that address.

This works. Many VoIP deployments, particularly small ones, use nothing more than A records and function perfectly well. But A records have significant limitations for VoIP:

**No port information.** An A record returns an IP address and nothing else. SIP's default port is 5060 for UDP and TCP, and 5061 for TLS. If your server runs on a non-standard port, you cannot express that in an A record. You have to configure the port explicitly on every phone.

**No transport selection.** An A record does not tell the phone whether to use UDP, TCP, or TLS. The phone either has to be explicitly configured with the transport, or it has to guess (and the guess varies by manufacturer).

**No failover.** If you have two SIP servers for redundancy, you can put two A records on the same hostname. But A records have no concept of priority. The phone gets back two IP addresses and picks one, typically the first one in the response. If that server is down, whether the phone tries the second address depends on the phone's implementation. Some do. Some do not. Some wait for a timeout that takes 30 seconds, during which all calls fail.

**No load distribution.** You can use DNS round-robin with multiple A records, but you cannot control the weighting. You cannot say "send 80% of traffic to server A and 20% to server B." Round-robin is random and uncontrollable.

For a single-server deployment with phones that are all explicitly configured with the right port and transport, A records are fine. For anything more complex, SIP has better tools.

## SRV records: the right way to find a SIP server

DNS SRV (service) records were designed to solve exactly the problems that A records cannot handle. An SRV record says: for this service, using this protocol, in this domain, connect to this server, on this port, with this priority and weight.

The format looks like this:

```
_sip._udp.example.com.  IN SRV  10 60 5060 sip1.example.com.
_sip._udp.example.com.  IN SRV  10 40 5060 sip2.example.com.
_sip._udp.example.com.  IN SRV  20 0  5060 sip-backup.example.com.
```

Let's break that down. The name `_sip._udp.example.com` means "the SIP service, over UDP, for the domain example.com." The fields after `SRV` are:

- **Priority** (10, 10, 20): Lower numbers are tried first. The two servers with priority 10 are primary. The server with priority 20 is a backup, only tried if both primaries are unreachable.
- **Weight** (60, 40, 0): Among servers with the same priority, weight controls load distribution. With weights of 60 and 40, roughly 60% of new connections go to sip1 and 40% go to sip2.
- **Port** (5060): The port to connect to. This can be different for each server.
- **Target** (sip1.example.com): The hostname of the server, which then requires its own A record lookup.

This is dramatically more useful than a bare A record. You get:

**Explicit failover.** Priority levels define a clear failover hierarchy. If all priority-10 servers are unreachable, the phone moves to priority 20. This is not implementation-dependent guessing. It is specified behavior.

**Load balancing.** Weights let you distribute traffic unevenly across servers. Useful when your servers have different capacities, or when you want to drain traffic from a server before maintenance.

**Port flexibility.** Each server can run on a different port, and the phone learns the port from DNS rather than from its local configuration.

**Transport awareness.** The `_udp` in the record name specifies the transport protocol. RFC 3263 defines separate SRV names for `_sip._tcp` and, for SIP over TLS, `_sips._tcp`; there is no `_sip._tls` record in the standard, though you will occasionally see vendors publish one as a non-standard convention. The phone can look up which transports are available and choose appropriately.

### How SRV lookups actually work

When a SIP phone is configured with a domain (just `example.com`, not a specific server hostname), and it needs to send a request, the lookup process defined in RFC 3263 is:

1. The phone constructs an SRV query: `_sip._udp.example.com` (or `_sip._tcp` / `_sips._tcp`, depending on configuration or NAPTR results).
2. The DNS server returns the SRV records, with priorities and weights.
3. The phone resolves the target hostname from the highest-priority SRV record to an IP address via a standard A (or AAAA) record lookup.
4. The phone attempts to connect to that IP on the specified port.
5. If the connection fails, the phone tries the next server according to priority and weight rules.

This is the mechanism that makes VoIP failover work at the DNS level. It is also the mechanism that breaks when DNS is misconfigured.

## NAPTR records: choosing the transport

NAPTR (Naming Authority Pointer) records add another layer on top of SRV records. Where SRV records answer "which server, which port," NAPTR records answer "which transport protocol should I use, and in what order should I try them?"

A NAPTR lookup for a SIP domain might return:

```
example.com.  IN NAPTR  10 0 "s" "SIPS+D2T" "" _sips._tcp.example.com.
example.com.  IN NAPTR  20 0 "s" "SIP+D2T"  "" _sip._tcp.example.com.
example.com.  IN NAPTR  30 0 "s" "SIP+D2U"  "" _sip._udp.example.com.
```

This says: for SIP services at example.com, first try SIP over TLS (`SIPS+D2T`), then SIP over TCP (`SIP+D2T`), then SIP over UDP (`SIP+D2U`). Each NAPTR record points to an SRV record name, and the SRV records point to actual server hostnames.

The full resolution chain is:

1. **NAPTR lookup** on `example.com` → determines available transports and their priority
2. **SRV lookup** on the selected service (e.g., `_sips._tcp.example.com`) → determines server, port, priority, weight
3. **A/AAAA lookup** on the server hostname (e.g., `sip1.example.com`) → determines IP address

Three DNS lookups before the phone sends its first SIP packet.

In practice, many VoIP deployments skip NAPTR entirely. The phone is configured with a specific transport (usually UDP or TLS), and it goes straight to the SRV lookup. NAPTR is most commonly seen in carrier interconnect scenarios, in IMS (IP Multimedia Subsystem) networks, and in deployments that want to enforce TLS-first policies via DNS rather than phone configuration. If your VoIP provider has not published NAPTR records, your phones are almost certainly not using them, and that is fine.

## ENUM: phone numbers in DNS

There is one more DNS-based system worth knowing about, though it is less commonly encountered in typical business VoIP. ENUM (E.164 Number Mapping) uses NAPTR records to map phone numbers to SIP URIs via DNS.

The idea is that if you want to call +1-212-555-0100, you can reverse the digits, separate them with dots, and append `e164.arpa` to get a DNS name: `0.0.1.0.5.5.5.2.1.2.1.e164.arpa`. A NAPTR lookup on that name might return a SIP URI like `sip:user@example.com`, allowing the call to be routed directly over IP without touching the PSTN.

ENUM saw some adoption among VoIP carriers as a way to keep inter-provider calls on-net (avoiding PSTN termination charges). Public ENUM never achieved widespread adoption for consumer numbers, but private ENUM is used within some carrier networks and peering arrangements for exactly this purpose: keeping calls that could be IP-to-IP from unnecessarily touching the PSTN.

For most businesses, ENUM is invisible. But if you are troubleshooting call routing anomalies where certain calls to certain numbers take unexpected paths, it is worth knowing that ENUM exists and might be in play at the carrier level.

## Why DNS failures hit VoIP so hard

When your DNS server goes down or becomes slow, web browsing degrades but mostly still works because browsers cache DNS responses aggressively and many connections are long-lived. VoIP is different in ways that make it far more sensitive to DNS problems.

### Registration depends on DNS

Your phone [re-registers](/blog/sip-registration) periodically, typically every 30 to 60 minutes, sometimes more often. Each re-registration may trigger a fresh DNS lookup, depending on the phone's implementation and the TTL (time to live) on the DNS records. If DNS is unreachable at the moment a phone tries to re-register, the refresh fails. That does not instantly unregister the phone; under RFC 3261, the registrar keeps the existing binding until it expires (or is explicitly removed), but once the previous registration's expiry passes without a successful refresh, incoming calls can no longer reach the phone.

If you have 50 phones and they all have slightly different registration timers, a DNS outage will cause phones to drop off in a staggered, seemingly random pattern as each phone's existing binding expires. Some phones re-registered recently and their registration has not expired yet, so they still receive calls. Others failed their refresh during the outage and have since aged out. This is why DNS outages often produce reports like "some phones work and some don't" rather than a clean, obvious total failure.

### Failover requires DNS

The entire SRV-based failover mechanism described above depends on DNS having worked at some point. A phone that has the full SRV record set cached can fail over among those targets immediately: RFC 3263's priority rules operate on the already-resolved list, with no new lookup and no waiting for TTL expiry. The failure case is a phone that only ever resolved the primary: if its cached answer contains a single address (a bare A record, or an implementation that discards the rest of the SRV set), finding the backup requires a fresh lookup, and if DNS is also down at that moment, failover does not happen. You have two points of failure (SIP server and DNS) that are supposed to be independent but might not be if they run on the same infrastructure or share the same network path.

### Low TTLs mean frequent lookups

VoIP providers often set low TTLs on their DNS records, sometimes as low as 60 seconds, because they want DNS changes to propagate quickly for failover purposes. To be precise, TTL controls how long a cached answer stays fresh, not how often a phone must query: a phone with a persistent TLS connection to its server may not resolve again for hours regardless of TTL. But for implementations that resolve on each transaction or refresh, a low TTL means frequent lookups. High TTLs mean phones can reuse cached answers longer and are less affected by brief DNS disruptions, but they are also slower to notice when a server changes.

This creates a tension. Low TTLs give you fast failover but make you more dependent on DNS availability. High TTLs give you resilience to DNS blips but slow down failover. Most providers choose low TTLs and accept the DNS dependency.

### DNS latency adds to call setup time

A DNS lookup that takes 500 ms instead of 5 ms adds 500 ms to the time it takes for a call to start ringing. If the lookup chain is NAPTR → SRV → A, and each step takes 500 ms, you have added 1.5 seconds to call setup. Users experience this as a long delay between dialing and hearing ringback. If the lookup times out entirely (several seconds, depending on the phone's resolver configuration), the call fails outright.

## Common DNS problems in VoIP deployments

### Using the wrong DNS servers

Phones should typically use the same DNS servers as the rest of your network. But some phone provisioning templates hardcode specific DNS servers, sometimes the VoIP provider's DNS servers. If those servers become unreachable from your network (firewall change, routing issue), the phones lose DNS while everything else on the network works fine. This produces the maddening symptom of "the internet works, everything else works, but the phones are down."

Check what DNS servers your phones are actually using. It is in the phone's network configuration, either set statically, delivered via DHCP option, or hardcoded in the provisioning file. Make sure those servers are reachable and responsive from the VLAN your phones are on.

### DNS servers on the wrong VLAN

If your phones are on a dedicated [voice VLAN](/blog/office-network-vlans) (and they should be), the DNS servers they use must be reachable from that VLAN. If your DNS server is on the data VLAN and inter-VLAN routing is misconfigured or blocked, phones cannot resolve hostnames. This is especially common after network changes when someone adjusts firewall rules or ACLs and forgets that the voice VLAN needs to reach the DNS server.

### Stale DNS cache

Some phones cache DNS responses beyond the stated TTL. If your VoIP provider changes their server IP addresses and your phone is still using the old cached address, the phone is sending SIP traffic to a server that no longer exists. A phone reboot forces a fresh DNS lookup. If rebooting a phone fixes a registration problem, stale DNS cache is a likely culprit.

### Split-horizon DNS issues

Organizations that use split-horizon DNS (internal DNS returns private addresses, external DNS returns public addresses) need to ensure that phones resolve VoIP hostnames to the correct addresses for their network location. A phone on the internal network that resolves the VoIP provider's hostname to a public IP might work (if the firewall handles [NAT hairpinning](/blog/sip-nat-traversal)), or it might not. A remote phone that resolves to an internal IP will definitely not work.

### DNS over blocked ports

DNS typically uses UDP port 53. Some networks block outbound DNS to prevent DNS-based data exfiltration or to force all DNS queries through an internal resolver. If phones are configured to use an external DNS server and port 53 is blocked outbound from the voice VLAN, DNS lookups fail silently and the phone cannot register.

## Verifying DNS for VoIP

When troubleshooting, you can manually perform the same DNS lookups a phone would make. From a machine on the same network (ideally the same VLAN) as the affected phones:

```bash
# Check for NAPTR records
dig NAPTR example.com

# Check for SRV records (UDP)
dig SRV _sip._udp.example.com

# Check for SRV records (TLS)
dig SRV _sips._tcp.example.com

# Resolve the server hostname
dig A sip1.example.com

# Test with a specific DNS server
dig @10.0.0.1 SRV _sip._udp.example.com
```

If any of these queries return no results, return unexpected results, or take more than a few hundred milliseconds, you have found a likely contributor to your VoIP problem.

Also check that the DNS server itself is responsive:

```bash
# Measure DNS query time
dig example.com | grep "Query time"
```

Query times under 10 ms to a local DNS server are normal. Query times over 100 ms indicate a problem. Query times over 500 ms will cause user-visible call setup delays.

## Best practices

**Use local DNS resolvers.** Phones should query a DNS server on your local network, not a remote public resolver. Local resolvers respond faster and are not affected by internet congestion. Your local resolver can forward to upstream servers (your ISP, Google, Cloudflare) for names it does not know, but the first hop should be local and fast.

**Ensure DNS redundancy.** Configure at least two DNS servers for your phones via DHCP. If one goes down, the phone falls back to the other. Make sure the two servers are not on the same physical machine or behind the same single point of failure.

**Monitor DNS.** If you are [monitoring your VoIP infrastructure](/blog/msp-proactive-monitoring), add DNS response time and availability to your checks. A DNS server that is up but responding slowly will cause intermittent VoIP problems that are extremely difficult to diagnose without DNS-specific monitoring.

**Match DNS servers to VLANs.** If you run separate VLANs for voice and data, verify that the DNS servers configured for the voice VLAN are reachable from that VLAN. Test this explicitly after any network configuration change.

**Know your TTLs.** Look up the TTL on your VoIP provider's DNS records. If they are low (under 300 seconds), phones that resolve on each transaction are doing frequent DNS lookups and are more sensitive to DNS disruptions. This is not something you need to change, but it is something you should be aware of when diagnosing intermittent problems.

## The bottom line

DNS is in the critical path of every VoIP call. It determines which server your phone talks to, which transport it uses, and whether failover works when a server goes down. When DNS is fast and reliable, it is invisible. When it is not, it produces some of the most confusing and intermittent VoIP failures you will encounter.

The good news is that DNS problems, once identified, are usually straightforward to fix. The hard part is recognizing that DNS is the problem in the first place. Now you know where to look.

*For more on how SIP registration works (and what happens when it fails), see [SIP Registration: How Your Phone Tells the World Where It Is](/blog/sip-registration). For a broader diagnostic framework, see [How to Tell Where the Problem Actually Is](/blog/diagnosing-voip-problems).*

---

## Why a Speed Test Can't Tell You If VoIP Will Work

URL: https://voiptest.com/blog/why-speed-tests-cant-measure-voip
Published: 2026-03-23
Category: Guides
Tags: voip-basics, speed-test, call-quality, jitter, packet-loss, network-testing

Search "VoIP test" online and most of what you find are speed tests with a VoIP label on them. They measure your download speed, your upload speed, maybe your ping, and then tell you whether your connection is "good for VoIP." Some of them even brand themselves specifically as a "VoIP Speed Test."

They are not wrong that bandwidth matters. If you have a 256 kbps DSL line trying to carry ten simultaneous calls, you have a bandwidth problem. But that scenario is increasingly rare. Most businesses have enough raw bandwidth for voice. The problems that actually cause bad call quality live in places that speed tests do not measure and, because of how they work, cannot measure.

This is not a minor gap. Speed tests and VoIP quality measurement are fundamentally different exercises. Understanding why is the first step toward actually diagnosing call quality problems instead of chasing bandwidth numbers that were never the issue.

## Speed tests use the wrong protocol

This is the most fundamental problem, and everything else flows from it.

Speed tests classically use TCP, and modern ones increasingly run over QUIC (the UDP-based transport under HTTP/3, RFC 9114) or WebSockets. VoIP uses RTP running over plain UDP with no reliability layer at all. The distinction that matters is not TCP versus UDP as such -- it is reliable bulk transfer versus unreliable real-time delivery. Every transport a speed test uses retransmits lost data and backs off under congestion; QUIC does this just as TCP does, only in user space. These transports behave so differently under stress from real-time media that measuring one tells you almost nothing about the other.

A reliable transport is designed for completeness. When a packet gets lost, it is detected and retransmitted. When the network gets congested, the sender backs off its rate to avoid making things worse. These are excellent features for loading web pages and downloading files. They are also the reason a bulk-transfer test cannot measure what VoIP experiences.

When a speed test encounters packet loss, its transport retransmits the lost data and slows down. The test completes successfully, maybe with a slightly lower throughput number. No packets are actually lost from the test's perspective because everything eventually arrives.

When a VoIP call runs over UDP and encounters packet loss, those packets are gone. There is no retransmission. The audio that was in those packets is simply missing. The listener hears a gap, a click, or a robotic artifact. The call keeps going at the same pace regardless because voice is real-time. It cannot pause and wait for a retransmit.

A connection can lose 3% of its UDP packets and a speed test will barely notice. That same 3% loss will make phone calls sound noticeably broken.

## Throughput is the wrong metric

Speed tests answer the question: how much data can this connection move per second? That is a useful number for many things. It is not useful for voice.

A single VoIP call using the G.711 codec requires about 87 kbps in each direction. Using Opus, it is even less: 24 to 48 kbps depending on configuration. Ten simultaneous G.711 calls need less than 1 Mbps of bandwidth. Most business connections today deliver 50 to 500 Mbps or more.

The bandwidth question was answered years ago for most offices. The connection is big enough. What matters now is the quality of the delivery: are those small, frequent voice packets arriving consistently, on time, and intact?

A speed test that reports 200 Mbps download and 20 Mbps upload tells you the pipe is wide enough. It says nothing about whether the packets flowing through it arrive with the timing precision that voice requires.

## Jitter is invisible to speed tests

[Jitter](/blog/what-is-jitter-and-why-it-matters) is the variation in packet arrival times. VoIP sends a packet roughly every 20 milliseconds. If those packets arrive at 18ms, 22ms, 19ms, 21ms intervals, the jitter is low and audio sounds clean. If they arrive at 8ms, 45ms, 12ms, 60ms intervals, the jitter is high and audio sounds choppy or robotic.

Speed tests do not measure jitter because they do not need to. Bulk-transfer traffic -- TCP and QUIC alike -- is reassembled in order regardless of when individual packets arrive. A web page loads the same whether its packets arrive with 2ms of jitter or 200ms of jitter. The browser waits for everything and renders the result.

Voice cannot wait. It plays back in real time. A phone's [jitter buffer](/blog/latency-jitter-packet-loss-details) collects incoming packets and tries to smooth out the variation, but it can only absorb so much. When a packet arrives outside the buffer window, it is functionally lost. High jitter creates packet loss even when every packet technically arrives at its destination.

A connection with 200 Mbps throughput and 40ms of jitter will pass every speed test while making every phone call sound terrible.

## Packet loss patterns matter, not just percentages

Even tests that report a packet loss number usually report it as a single percentage: "0.5% packet loss." That number alone does not tell you much about voice quality because the pattern of loss matters enormously.

Half a percent of random, evenly distributed loss is manageable. Modern codecs and packet loss concealment algorithms can mask the occasional missing packet well enough that most listeners will not notice.

Half a percent of loss concentrated in bursts is a different story. Five consecutive lost packets at 20ms each creates a 100-millisecond hole in the conversation. That is an entire syllable gone. The listener hears a hard cut in the audio, and no amount of concealment can fill a gap that large convincingly.

Speed tests have no concept of loss patterns because their reliable transport retransmits everything. And even network monitoring tools that do measure UDP loss rarely distinguish between random and [burst loss](/blog/understanding-voip-packet-loss). VoIP quality depends on knowing the difference.

## Buffer bloat turns good bandwidth into bad calls

[Buffer bloat](/blog/what-is-jitter-and-why-it-matters) is a specific failure mode where routers and modems have oversized packet buffers. When the connection gets busy, instead of dropping excess packets (which TCP would detect and respond to by slowing down), the equipment queues them in a large buffer. The packets eventually get through, but they wait in line for tens or hundreds of milliseconds first.

The result is that throughput looks fine but latency spikes dramatically under load. A connection that pings at 15ms when idle might jump to 300ms or more when someone starts a large download.

Here is the irony: speed tests actively trigger buffer bloat during measurement. They saturate the connection to measure maximum throughput. The buffer fills up. The speed test reports the throughput number as a success. Meanwhile, the latency spike that occurred during that saturation is exactly what would destroy a phone call happening at the same time.

A speed test cannot warn you about buffer bloat because the speed test is the thing causing it, and the speed test only reports the metric that buffer bloat does not affect.

## Latency under load vs. idle latency

Most speed tests report a "ping" or latency number. This is typically measured either before the throughput test starts (idle latency) or during it (loaded latency). Neither tells the full story for VoIP.

Idle latency tells you the best case. It is useful as a baseline, but calls do not happen in isolation. While someone is on a call, other people in the office are browsing the web, pulling files from cloud storage, uploading to SaaS apps, and generating all the other traffic that a modern office produces.

Loaded latency during a speed test tells you the worst case under full saturation, which is also not realistic. Nobody sustains 100% link utilization during normal work.

What matters for VoIP is latency during typical mixed use. A connection that shows 12ms idle and 180ms loaded might sit at 35ms during a normal workday, which is fine for voice. Or it might spike to 120ms every time someone opens a large email attachment, which is not. Speed tests do not model this middle ground.

## QoS hides the real picture

Some business networks have Quality of Service policies that prioritize voice traffic on the local network. When QoS is active, voice packets skip ahead of file transfers and backups at the router's outbound queue. A speed test does not benefit from this prioritization, so it measures the unprioritized path. On a QoS-enabled network, the speed test might report worse conditions than voice actually experiences locally.

But this distinction matters less than the QoS conversation usually implies. QoS only operates on equipment you control -- your switches and your router. Once packets leave your network and enter your ISP's infrastructure, DSCP markings are generally ignored, remarked, or stripped -- each network domain applies its own policy. Consumer and most business internet connections do not honor them. Your ISP has no reason to give your traffic priority over anyone else's unless you are paying for a dedicated SLA that specifically includes it.

This means QoS protects voice from congestion on your own LAN, but it does nothing for the internet leg of the call, which is where most VoIP quality problems actually originate. And on the LAN side, if you need QoS to keep calls clean, that is a signal that your network is congested -- QoS is treating the symptom, not the cause. For most small and medium businesses, a properly sized router and adequate bandwidth do more for call quality than QoS policy tuning ever will.

## No codec context

A speed test cannot tell you how different VoIP codecs will perform on your connection because codec selection changes which network characteristics matter most.

[G.711](/blog/what-is-voip) uses uncompressed audio at a fixed 64 kbps bitrate. It produces excellent audio quality on clean connections but has no built-in resilience to packet loss. Every lost packet is a hard gap in the audio.

[Opus](/blog/what-is-voip) is a modern codec that operates at variable bitrates and includes forward error correction. It can recover from moderate packet loss far better than G.711. On a connection with 1% random loss, Opus with FEC enabled might sound nearly perfect while G.711 sounds noticeably degraded.

The practical implication is that the same connection can produce very different call quality depending on which codec is in use. A VoIP-specific test can compare codec performance under your actual network conditions and show you that switching from G.711 to Opus (or vice versa) would change your experience. A speed test has no framework for this kind of analysis.

## Directional asymmetry

Speed tests do measure upload and download separately, which is good. But they measure throughput in each direction, not quality.

Jitter and loss can be completely different on the upstream versus downstream path. Your router's upload queue might be congested while your download path is clean, or your ISP might have an asymmetric issue on their network that affects one direction more than the other.

In a phone call, this means you might sound fine to the other person while they sound terrible to you, or the reverse. "One-way bad audio" is a specific and common VoIP complaint that requires per-direction quality measurement to diagnose. Knowing that your upload speed is 20 Mbps and your download is 200 Mbps tells you nothing about which direction has the jitter problem.

## Concurrent call capacity is not a bandwidth calculation

Some speed test results pages include a "VoIP calls supported" estimate. They take your measured bandwidth, divide by the bandwidth per call (usually assuming G.711 at ~87 kbps), and give you a number. "Your connection supports 230 simultaneous VoIP calls."

This calculation is technically correct and practically useless. Bandwidth per call is a necessary condition, not a sufficient one. The actual limit on concurrent calls is determined by how the network handles the aggregate packet flow: does jitter increase as more calls are added? Does the router's NAT table handle hundreds of concurrent UDP sessions cleanly? Does the firewall's packet inspection add latency as session count grows?

A connection with 20 Mbps upload bandwidth could theoretically carry 230 G.711 calls. In practice, the router might start dropping packets at 15 concurrent calls because its CPU cannot keep up with the NAT translations. The speed test's bandwidth-based estimate is off by an order of magnitude.

## What does a real VoIP test measure?

The gaps above are not academic. They describe the specific reasons that businesses with plenty of bandwidth still have terrible call quality, and why running a speed test to diagnose the problem leads nowhere.

A test designed for voice needs to:

- **Send UDP traffic matching VoIP patterns.** Small packets at regular intervals, not bulk TCP transfers. This measures the actual transport path that voice uses.
- **Measure jitter per packet, not averages.** Per-packet timing reveals spikes and patterns that averages conceal.
- **Track packet loss patterns.** Random loss versus burst loss versus periodic loss. Each has different causes and different impacts on audio quality.
- **Test under realistic conditions.** Not idle, not saturated, but representative of actual use.
- **Measure real concurrency.** Several calls running at once, competing for the connection, rather than one call's numbers multiplied out.
- **Calculate standards-based quality scores.** [MOS scores](/blog/understanding-mos-scores) derived from ITU-T G.107, not proprietary formulas. Defensible, reproducible, industry-standard.

That is the kind of test we built. Our [VoIP quality test](/tools/voip-test) is not a speed test with a label. It is a diagnostic engine built around how voice traffic actually behaves. For how to use those measurements methodically (baseline tests, loaded tests, comparative tests, and before-and-after validation), see our [VoIP quality testing methodology guide](/blog/voip-quality-testing-guide).

---

*Evaluating a specific tool rather than the category? [How to Tell If a VoIP Test Is Actually Testing VoIP](/blog/is-your-voip-test-actually-testing-voip) turns the reasoning above into nine things you can check from the outside in about a minute.*

*Wondering what jitter, packet loss, and latency actually do to your calls? Start with [What Is Jitter and Why Does It Wreck Your Calls?](/blog/what-is-jitter-and-why-it-matters) or read the full [VoIP From the Ground Up](/blog/series/voip-from-the-ground-up) series for the complete picture.*

---

## What Happens to Your Phones When the Internet Goes Down

URL: https://voiptest.com/blog/what-happens-to-phones-when-internet-goes-down
Published: 2026-03-21
Category: Guides
Tags: voip-basics, business-voip, failover, reliability, voip-fundamentals

Every business that considers switching to VoIP asks the same question: "What happens when the internet goes down?"

It is a fair question. With traditional phone lines, the phone system and the internet were completely separate. You could lose your internet connection and still make calls. VoIP ties your phones to your internet connection, and that feels like putting all your eggs in one basket.

Here is the truth: an internet outage does not have to mean phone silence. But it will, if you have not planned for it. This post covers exactly what happens to your phones when connectivity drops, what your provider does (or does not do) on their end, and how to set up your system so that calls keep flowing even when your internet does not.

## The first thirty seconds: what your phones actually do

When your internet connection drops, your VoIP phones do not immediately know the internet is gone. They know something is wrong, but they cannot tell the difference between "the internet is down" and "there is a brief network hiccup."

Here is a typical sequence. The exact timing is an example, not a rule: it depends on your phones' keepalive and registration intervals (SIP registration expiry is negotiated between the phone and the registrar under RFC 3261) and on your provider's configuration:

**Seconds 0-5.** Active calls drop. If you are on a call when the connection fails, the audio stops. VoIP sends [packets every 20 milliseconds](/blog/what-happens-when-you-press-call), and when those packets suddenly stop arriving, both sides hear silence. After a few seconds of silence, most VoIP applications and desk phones recognize the call has been lost and disconnect it. There is no graceful goodbye. The call simply ends.

**Seconds 5-15.** Phones detect the problem. Your desk phone or softphone tries to send its regular keepalive messages to the VoIP provider's server. Some of these are frequent NAT keepalives sent every few seconds; others are registration refreshes (how your phone says "I'm still here, still reachable at this address"), which may only fire every few minutes, depending on the registration interval negotiated with the provider. When those messages get no response, the phone knows something is wrong. A phone that relies solely on infrequent registration refreshes may not notice the outage for minutes rather than seconds.

**Seconds 15-30.** Phones show an error state. The display changes. Desk phones typically show "No Service," "Network Unavailable," or "Unregistered." Softphone apps show a red indicator or a connection error banner. The phone starts trying to reconnect, sending registration attempts at increasing intervals.

At this point, your phones are paperweights. They cannot make or receive calls. The handsets still have power (assuming they are plugged in or have battery), but they have no connection to the phone system.

## What happens to calls people try to make to you

This is where it gets interesting, and where preparation matters enormously. When someone calls your business number during an outage, the call does not just vanish into a void. It goes to your VoIP provider's servers, which are almost certainly not affected by your local internet outage. Those servers are in data centers with redundant connections.

Your provider receives the incoming call and tries to deliver it to your phones. It sends the call signaling to the IP address where your phones were last registered. That signaling gets no response, because your internet connection is down.

What happens next depends entirely on how your provider is configured. Even the detection step varies: some platforms treat a failed call delivery as unreachable immediately, while others wait for your phones' registrations to expire, an interval that is provider- and configuration-specific. The scenarios below are the common patterns:

### Scenario 1: No failover configured

The provider tries to reach your phones, fails, and the caller hears ringing that goes unanswered, or the call goes to a generic voicemail box. If voicemail is not set up, the caller might get a "this number is not available" message or just endless ringing. This is the worst case and, unfortunately, the default for many small business VoIP setups.

### Scenario 2: Voicemail catches the call

If voicemail is configured, the provider waits a few seconds for your phones to respond, then redirects the call to voicemail. The caller can leave a message, and you will get it (usually as an email notification or in the app) once your connection is restored or if you check from a mobile device. Better than nothing, but a customer calling with an urgent issue does not want to leave a message.

### Scenario 3: Automatic failover to mobile

Many VoIP providers offer "find me / follow me" or simultaneous ring features. When your desk phone does not answer within a set number of rings, the system automatically forwards the call to your mobile phone over the regular cellular network. The caller may not even realize anything is wrong. They called your business number, it rang a couple extra times, and you answered.

### Scenario 4: Cloud-based automatic rerouting

More sophisticated providers, particularly cloud PBX platforms, detect that your phones are unregistered and immediately reroute calls according to rules you have configured in advance. Calls might go to a different office location, to mobile phones, to an auto-attendant that gives callers options, or to a call queue staffed by remote workers on a different internet connection. This happens automatically, with no human intervention needed.

The difference between scenario 1 and scenario 4 is not technology. The technology exists in nearly every modern VoIP platform. The difference is whether someone took thirty minutes to configure it.

## What you can still do during an outage

Your desk phones are down, but you probably still have options:

**Mobile softphone apps.** If your VoIP provider has a mobile app (most do now), and your phone has cellular data, you can make and receive calls on your business number from your mobile phone. You are going around the outage entirely, using the cellular network instead of your office internet to reach the VoIP provider. Your caller ID still shows your business number. The other party has no idea you are standing in a parking lot waiting for your ISP to fix things.

**Wi-Fi calling from a neighbor or hotspot.** If the outage is your office internet specifically, connecting a laptop or phone to a mobile hotspot or a nearby Wi-Fi network lets your softphone reconnect. Not ideal for an entire office, but it works for keeping one or two critical lines alive.

**Forwarding at the provider level.** Even without a mobile app, you can usually log into your VoIP provider's web portal (from your phone's cellular browser) and manually set up call forwarding to a mobile number. This is the manual version of the automatic failover described above.

**Traditional cellular calls.** If nothing else works, you have a phone in your pocket. You can make outbound calls from your personal mobile number. Not professional, but functional. Some VoIP providers offer a feature where outbound calls from your mobile can be routed through their system so that your business caller ID is displayed.

## The outage everyone forgets: power

Internet outages get all the attention, but power outages are just as disruptive and more common. Here is what happens:

**Your router and switches lose power.** Even if your ISP's network is fine, your office network equipment needs electricity. No power to the router means no internet means no VoIP, same result as an internet outage.

**PoE phones lose power too.** Most desk phones are powered by Power over Ethernet from the network switch. When the switch loses power, the phones go dark entirely. No display, no nothing.

**The ISP's equipment may fail too.** If you have fiber, the ONT (the box where fiber enters your building) needs power. Many ISPs provide a small battery backup for the ONT, but those batteries typically last only a few hours. Cable modems and DSL modems also need power.

A UPS (uninterruptible power supply) on your router, switch, and ISP equipment gives you a buffer. A typical UPS can keep this gear running for 30 to 90 minutes, long enough to ride out most power blips and short enough to be affordable. For longer outages, you need either a generator or a cellular failover strategy.

## How to set up your system so outages do not mean silence

This is the practical part. Here is what to configure, roughly in order of importance:

### 1. Configure call forwarding rules now, before you need them

Log into your VoIP provider's admin portal. Set up failover rules for every user and every ring group:

- If the desk phone does not answer in 15 seconds, ring the user's mobile phone.
- If the mobile does not answer in 15 seconds, go to voicemail.
- For main business numbers and ring groups, configure simultaneous ring to mobile phones so there is zero delay.

Do this today. Not when the outage happens. During an outage you may not have convenient access to the admin portal, and you will be too busy dealing with the immediate crisis to configure routing rules calmly.

### 2. Install your provider's mobile app

Every user who receives important calls should have the VoIP provider's mobile app installed on their phone, logged in, and tested. The app should be configured to use cellular data as a fallback when Wi-Fi is unavailable.

Test it. Turn off Wi-Fi on your phone and make a call through the app. If it works on cellular, you have a working backup. If you have never tested it, you do not have a backup. You have a hope.

### 3. Get a cellular failover device

For businesses where phone availability is critical, a cellular failover router is the gold standard. This is a device that sits alongside your primary router and contains a cellular SIM card. When it detects that your primary internet connection is down, it automatically activates the cellular connection and routes traffic through it.

Modern failover routers are smart. They can prioritize VoIP traffic on the cellular connection, ensuring that even if the cellular bandwidth is limited, voice calls get through. Some can even keep existing calls alive during the switchover if the failover happens fast enough.

The cost is the device itself (a few hundred dollars) plus a cellular data plan. For a business that loses revenue when phones are down, this pays for itself the first time it is needed.

### 4. Consider SD-WAN for multiple connections

If your business has two internet connections, say a primary fiber line and a backup cable connection, an SD-WAN solution can automatically route VoIP traffic over whichever connection is currently working best. If one goes down, traffic fails over to the other with no manual intervention and often no noticeable interruption.

SD-WAN is more common and more affordable than it used to be. Many business routers now include basic SD-WAN capabilities. For businesses with [dedicated internet access](/blog/dedicated-internet-access) as a primary line and a cheaper cable connection as backup, this provides robust [redundancy](/blog/redundancy-failover).

### 5. Put critical network equipment on UPS

At minimum, put your router, your main network switch, and your ISP's equipment (modem, ONT) on a UPS. This keeps your phones alive during brief power interruptions, which account for a surprising number of "outages."

A $150 UPS that keeps your network stack running for 45 minutes eliminates the single most common cause of VoIP downtime for small businesses.

### 6. Set up monitoring and alerts

You should know about an outage before your customers tell you. Configure your VoIP provider's monitoring to alert you (via SMS to your mobile, not via email to your office computer) when phones go unregistered. Many providers offer this. If yours does not, a simple network monitoring tool that pings your office IP and texts you when it goes down serves the same purpose.

Knowing about the problem within minutes means you can activate manual failover procedures, notify staff to switch to mobile apps, and communicate proactively with customers rather than reactively.

## The hidden advantage of hosted VoIP: nothing lives at your office

Here is something that gets lost in the "what if the internet goes down" conversation: with a hosted VoIP system, your actual phone system is not in your building.

With an on-premises PBX, traditional or IP-based, the brains of your phone system sits in a server closet in your office. If your building loses power, floods, catches fire, or simply has a bad router, the entire phone system goes down. The hardware that routes calls, stores voicemail, and manages your auto-attendant is physically present and physically vulnerable.

With hosted VoIP, none of that is in your building. The call routing logic, the voicemail system, the auto-attendant, the call queues, the recording infrastructure: all of it runs in your provider's data center. That data center has redundant power, redundant internet, redundant cooling, and redundant hardware. It is engineered to stay running when your office cannot.

Your desk phones are just endpoints. They are the equivalent of a monitor plugged into a remote computer. When your internet goes down, the monitor goes dark, but the computer is still running. The phone system is still live, still accepting incoming calls, still capable of routing them according to your rules. It just cannot reach the endpoints in your office.

This is the fundamental difference from on-premises systems and the reason hosted VoIP can actually be more resilient, not less. When your internet goes down:

- **On-premises PBX**: The phone system itself is unreachable. Incoming calls cannot be processed at all. No voicemail, no forwarding, no auto-attendant. The system is as dead as your internet connection.
- **Hosted VoIP**: The phone system is fully operational. It receives incoming calls, recognizes that your desk phones are unregistered, and executes whatever failover rules are configured. Forward to mobile, send to voicemail, route to another location, play a custom message. The intelligence is in the cloud, not in your building.

This also means recovery is fundamentally different. When your internet comes back after an on-premises PBX outage, you might need to reboot servers, wait for the PBX to restart, and hope that everything reinitializes correctly. With hosted VoIP, your phones simply re-register with the cloud platform and are immediately back online. There is nothing to reboot, nothing to recover. The phones reconnect and calls flow again.

The businesses most at risk during an internet outage are, counterintuitively, the ones with expensive on-premises IP-PBX systems. They have the same internet dependency as hosted VoIP but without the cloud-based failover safety net. Their phone system is both internet-dependent and locally vulnerable, the worst of both worlds.

## What about the old phone system?

People sometimes argue that traditional phone lines were more reliable, and they are right. Copper phone lines carried their own power and worked during power outages. The public switched telephone network was engineered for five nines of reliability: 99.999% uptime, or about five minutes of downtime per year.

But that comparison misses context. Traditional phone systems had their own failure modes: PBX hardware failures, T1 line cuts, PRI card failures, analog line quality degradation. And when a traditional PBX failed, you needed a technician with specialized knowledge and possibly proprietary parts to fix it. Recovery could take hours or days.

A well-configured cloud VoIP system with cellular failover can match or exceed the practical reliability of a traditional phone system. The failure modes are different, not necessarily worse. And when something does fail, the recovery options are faster and more flexible. Forwarding calls to mobile phones takes seconds. Replacing a failed T1 card took a truck roll.

The key phrase is "well-configured." A VoIP system with no failover planning is genuinely less reliable than a traditional phone line. A VoIP system with proper failover planning is at least as reliable and far more flexible.

## The real risk is not the technology

The biggest risk in VoIP reliability is not the technology. It is the gap between what the technology can do and what someone actually configured it to do.

Every major VoIP provider offers failover routing, mobile apps, and call forwarding rules. The features exist. But they require someone to set them up, test them, and maintain them. The businesses that experience total phone silence during an outage almost always have access to the tools that would have prevented it. They just never configured them.

This is not a technology problem. It is a planning problem. And it is completely solvable.

Spend thirty minutes this week. Set up your failover rules. Install the mobile app. Test a call over cellular. Run a [VoIP quality test](/tools/voip-test) over both your primary connection and your failover to confirm each one can support voice traffic. Future you, standing in the office watching the router lights go dark, will be grateful.

---

*For a complete picture of how VoIP calls work and where they can break down, see [What Happens When You Press the Call Button](/blog/what-happens-when-you-press-call). To understand the network factors that affect reliability, our [Getting the Internet Right](/blog/series/getting-the-internet-right) series covers everything from [choosing an ISP](/blog/how-to-choose-isp) to [redundancy and failover planning](/blog/redundancy-failover).*

---

## What Happens When You Press the Call Button

URL: https://voiptest.com/blog/what-happens-when-you-press-call
Published: 2026-03-20
Category: Fundamentals
Tags: voip-basics, how-voip-works, call-quality, voip-fundamentals

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 two to five 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 160 bytes of data, depending on the codec: G.711 at 20 milliseconds is 160 bytes on its own, while a compressed codec manages a fraction of that. 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](https://www.rfc-editor.org/rfc/rfc3551.txt).

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](/blog/wired-vs-wifi-for-voip), 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)](/blog/quality-of-service-explained) 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](/blog/isp-foundation) 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 path that was reserved in advance, but it is not randomly re-routed either. Where multiple equal-cost paths exist, routers hash each flow (the source and destination addresses and ports) onto one of them, deliberately keeping all the packets of your call on the same path so they do not arrive out of order. The path changes when routing changes (a link fails, a peering shifts), not packet by packet.

The physical journey is remarkable. If you are calling someone across the country, your voice packet might travel through fiber optic cables at roughly two-thirds the speed of light in vacuum, 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 billions of packets per second.

Each router the packet passes through adds delay, but it helps to separate the components. The forwarding decision itself (receive, look up, forward) is commonly microseconds to well under a millisecond on modern hardware. Serializing a small voice packet onto a fast link is faster still. What actually dominates the end-to-end delay is propagation (distance at the speed of light in fiber) and queueing: time spent waiting behind other traffic at congested links. A path's latency is mostly a story about how far the packet travels and how full the queues are along the way, not a fixed per-router tax.

## Step 9: Some packets do not make it

Here is the reality of the internet: [not every packet arrives](/blog/understanding-voip-packet-loss). Routers get congested and drop packets. Links develop errors. Equipment fails. How much loss you actually see varies enormously by path and time of day: a healthy, uncongested path can run for hours with essentially zero loss, while a congested or faulty one can lose packets in bursts. There is no universal baseline number, which is exactly why loss is something you measure on your own path rather than assume.

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](/blog/choppy-robotic-audio).

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](/blog/what-is-jitter-and-why-it-matters), 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). Because the decoder has to produce sound on schedule, real-time PLC typically extrapolates from the audio it already played, continuing the pitch and spectral shape of the previous samples into the gap. Some codecs can do better when a later packet arrives in time: [Opus's in-band forward error correction embeds a coarse copy of each frame in the following packet](https://www.rfc-editor.org/rfc/rfc6716.txt), but using it means holding playback long enough for that next packet to arrive. For short gaps, one or two packets, concealment 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 (the one-way, mouth-to-ear delay) typically takes between 50 and 300 milliseconds. [ITU-T G.114](https://www.itu.int/rec/T-REC-G.114/en), the transmission-planning reference for one-way delay, uses 150 ms as a commonly cited planning boundary, not a point where audio suddenly fails: conversational comfort degrades gradually as total mouth-to-ear delay grows and depends heavily on echo control. Under about 150 ms one-way, conversation feels natural and real-time. As delay climbs toward 300 ms, you start noticing [delay](/blog/audio-delay-talking-over) and people begin talking over each other. Beyond that, 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](/blog/how-internet-connections-work), geographic distance, or an overloaded jitter buffer. Steps 8 and 10.

**Fine in the morning, bad in the afternoon?** [Network congestion](/blog/afternoon-call-quality) that builds during business hours. Steps 7 and 8.

**Bad on Wi-Fi, fine on Ethernet?** [Your wireless network](/blog/wired-vs-wifi-for-voip) 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](/blog/series/voip-from-the-ground-up) series covers each of these concepts in detail, from [how traditional phone calls work](/blog/how-does-a-phone-call-actually-work) to [diagnosing specific quality problems](/blog/diagnosing-voip-problems). For the protocol-level details of call signaling, see our [SIP Signaling](/blog/series/sip-signaling-from-the-wire-up) series.*

---

## Understanding VoIP Packet Loss: What It Means for Call Quality

URL: https://voiptest.com/blog/understanding-voip-packet-loss
Published: 2026-03-13
Category: Guides
Tags: packet-loss, voip-basics, call-quality

## What is packet loss?

When you make a VoIP call, your voice is broken into small data packets that travel across the internet to the other person. Packet loss occurs when some of those packets never arrive. The result: gaps in audio, [robotic-sounding speech](/blog/choppy-robotic-audio), or words that simply disappear mid-sentence.

Even a small amount of packet loss can degrade a conversation. As a rough guide, listeners often notice subtle artifacts around 1% loss, calls become difficult around 3-5%, and above 5% communication tends to break down. How audible a given loss rate actually is depends on the codec, the packetization interval, any concealment or forward error correction in use, and whether the loss is scattered or clustered: one lost 20ms packet removes 20ms of audio regardless of which codec filled it.

## Why packets get lost

Packet loss has several common causes, and understanding which one is affecting your network is the first step toward fixing it.

### Network congestion

The most frequent culprit. When too many devices or applications compete for bandwidth, routers start dropping packets they cannot handle. This is especially common on shared office networks during peak hours, or on home connections where a video stream is competing with your phone system.

### Faulty hardware

Aging switches, damaged cables, or overheating routers can all introduce packet loss. If the problem is consistent regardless of time of day or network load, hardware is a likely suspect.

### Wireless interference

Wi-Fi introduces an entire layer of potential loss. Microwave ovens, Bluetooth devices, neighboring access points on the same channel. All of these can cause packet drops on [wireless connections](/blog/wired-vs-wifi-for-voip). For VoIP, a wired connection is always preferable.

### ISP issues

Sometimes the problem is upstream. Poor peering between ISPs, oversubscribed links, or routing inefficiencies can all cause packet loss between your network and your VoIP provider. These issues are harder to diagnose because they happen outside your network boundary.

### Misconfigured QoS

[Quality of Service (QoS)](/blog/quality-of-service-explained) settings prioritize certain types of traffic. When misconfigured, voice packets may be treated as low priority and dropped first during congestion. Properly configured QoS should give voice traffic the highest priority on your local network.

## How to measure packet loss

Basic network tools like ping can give you a rough indication of packet loss, but they do not tell the full story for voice traffic. VoIP packets use UDP rather than TCP, which means lost packets are not retransmitted. They are simply gone. A ping test using ICMP may show different results than what your actual voice traffic experiences.

For accurate measurement, you need a test that simulates real voice traffic patterns: small packets sent at regular intervals, using UDP, with results measured over a meaningful time period. Our [VoIP quality test](/tools/voip-test) does exactly this. Single-point-in-time tests can miss intermittent issues that only appear during peak usage.

## What "acceptable" looks like

There is no single ITU-T pass/fail ladder for packet loss. The E-model (ITU-T G.107), the transmission-planning model behind most [MOS estimates](/blog/understanding-mos-scores), rates the impact of a given loss percentage differently depending on the codec, its concealment behavior, and how bursty the loss is. That said, these bands are useful operating targets for common codecs with modern loss concealment:

- **Below 1%**: Imperceptible to most listeners. This is the target.
- **1-2.5%**: Noticeable artifacts on careful listening. Usable but degraded.
- **2.5-5%**: Clearly impaired. Frequent audio gaps and distortion.
- **Above 5%**: Unusable for professional communication.

The pattern matters as much as the percentage: the same 1% loss is far more audible when it arrives in bursts of consecutive packets than when it is scattered randomly, which is why RTCP XR (RFC 3611) reports burst and gap loss separately rather than a single rate. Older codecs, short-on-FEC configurations, or poorly implemented [jitter buffers](/blog/what-is-jitter-and-why-it-matters) will show degradation at even lower loss rates.

## What you can do

If you have identified packet loss as your quality problem, here are the practical steps:

**On your network:** Implement QoS to prioritize voice traffic. Move VoIP endpoints to wired connections. Segment voice traffic onto a dedicated VLAN. Replace aging network hardware.

**With your ISP:** Share test results that show packet loss occurring beyond your network boundary. Traceroute data showing where loss begins gives your ISP something actionable to investigate.

**With your VoIP provider:** Ask about codec options. Some codecs like Opus handle loss better than others through built-in redundancy and interpolation. Ask whether your provider supports packet loss concealment (PLC) algorithms.

## The blame game

Here is the reality most VoIP users face: when call quality suffers, the ISP blames the VoIP provider, and the VoIP provider blames the ISP. Without independent test data showing exactly where the problem occurs, you are stuck in the middle with no leverage.

This is the problem VoIP Test was built to solve. Independent, data-driven analysis that shows you, and your providers, exactly where the breakdown happens.

---

*Want to understand how packet loss interacts with latency and jitter? See [Latency, Jitter, and Packet Loss: The Details](/blog/latency-jitter-packet-loss-details). For the full picture of how data moves across networks, start with [Packets: How Data Actually Moves](/blog/how-data-moves-in-packets) in our [VoIP From the Ground Up](/blog?category=fundamentals) series.*

---

## VoIP Quality for Remote Teams: What IT Should Be Monitoring

URL: https://voiptest.com/blog/voip-quality-for-remote-teams
Published: 2026-03-01
Category: Industry
Tags: remote-work, monitoring, it-ops

## The visibility problem

When everyone worked in the office, IT controlled the network end to end. Switches, routers, QoS policies, ISP uplinks. If call quality dropped, someone could walk to the network closet and start diagnosing.

Remote work changed that equation. Voice traffic now starts on a home network that IT has never seen, crosses a residential ISP that IT has no relationship with, traverses the public internet, and arrives at the VoIP provider. IT's visibility covers maybe the last hop. Everything before that is a black box.

This is not a theoretical problem. In most organizations with remote workers, the first indication of a voice quality issue is a complaint on Slack: "My calls sound terrible today." By the time someone looks into it, the problem may have resolved itself, leaving no data to analyze.

## What changed with remote work

Office networks are purpose-built. Dedicated bandwidth, QoS configuration, wired connections, enterprise-grade access points. Home networks are not.

**Shared bandwidth.** A remote worker's video call competes with their kid's game download and their partner's streaming. A 100 Mbps residential connection has plenty of bandwidth, but when it gets saturated, everything degrades at once because there is no QoS to protect voice traffic.

**Consumer-grade hardware.** Home routers often have oversized buffers (bufferbloat), no QoS support, and firmware that rarely gets updated. The ISP-provided router/modem combo is usually the worst offender.

**[Variable ISP quality.](/blog/isp-foundation)** Residential internet service has different SLAs than business service. Oversubscription ratios are higher. Maintenance windows are less predictable. And the "up to" speeds in the marketing materials have a lot of room between them and reality.

**[Wi-Fi](/blog/wired-vs-wifi-for-voip) everywhere.** In the office, VoIP phones sit on wired connections. At home, almost everything is wireless. The laptop on the kitchen table connects over Wi-Fi to a router two rooms away, and nobody thinks about it until calls start breaking up.

## The metrics that matter

If you are going to monitor VoIP quality for remote workers, focus on these four metrics. Everything else is either derived from these or secondary.

### Packet loss

The single most impactful metric. Even [1% packet loss](/blog/understanding-voip-packet-loss) can produce audible degradation, though how audible depends on the codec, its packet loss concealment, and whether the loss is scattered or bursty. Measure it with UDP traffic that mimics voice packet patterns (small packets at regular intervals), not with ICMP ping, which often gets different treatment on the network.

Track both average loss and burst loss. A worker with 0.5% average loss spread evenly sounds fine. A worker with 0.5% average loss concentrated in 2-second bursts every few minutes sounds terrible.

### Jitter

[Variation in packet arrival times](/blog/what-is-jitter-and-why-it-matters). As an operating target, keeping it under 30ms leaves comfortable headroom; sustained jitter above 50ms usually means the connection needs significant buffer compensation, which adds latency. These are practical monitoring thresholds, not standards limits; what actually matters is how much delay and late-packet discard the endpoint's jitter buffer incurs absorbing it.

Home Wi-Fi and bufferbloat are the most common causes of high jitter on remote connections.

### Latency

Delay matters for conversational flow, and be careful to note whether a tool reports one-way or round-trip figures, because they differ by roughly a factor of two. ITU-T G.114 uses 150ms of one-way *mouth-to-ear* delay as a transmission-planning boundary; it is a planning reference, not a point where audio suddenly fails. Mouth-to-ear covers the whole path, so halving a network round-trip figure still understates it: encoding, packetization and the jitter buffer all spend part of the same budget. As one-way delay climbs past it, people increasingly notice lag and talk over each other, and well above it natural conversation becomes difficult.

For most domestic remote workers, round-trip latency to the VoIP provider should be well under 100ms as an operating target. If it is not, there is likely a routing issue.

### [MOS (Mean Opinion Score)](/blog/understanding-mos-scores)

A composite estimate that rolls the above into a single quality score: most monitoring tools compute it from the ITU-T G.107 E-model, a transmission-planning calculation, rather than from actual listener ratings. Useful for dashboards and alerting, but always dig into the component metrics when investigating an issue.

## What IT can actually do

You do not control the home network. That is the uncomfortable reality. But you are not completely helpless.

**Establish a baseline for each worker.** Run a [VoIP quality test](/tools/voip-test) during onboarding or periodically. Know what each person's home connection looks like so you have something to compare against when problems arise.

**Provide guidance on home network setup.** Publish a simple guide: use the 5 GHz band, sit near the access point, use an Ethernet cable for your workstation if possible, check for bufferbloat. Most remote workers will follow straightforward advice if you give it to them.

**Offer to ship Ethernet cables and USB adapters.** A $15 USB-C to Ethernet adapter and a 10-foot cable solve half of all home VoIP quality issues. Many IT teams have found this to be the single highest-ROI investment for remote call quality.

**Enable endpoint quality reporting** in your VoIP platform. Most modern platforms (Teams, Zoom Phone, RingCentral, 8x8) collect call quality metrics from the client. Set up dashboards to spot workers who consistently report poor metrics.

**Set up proactive monitoring.** Rather than waiting for complaints, run periodic quality probes from remote locations to your VoIP infrastructure. This gives you trend data and lets you catch degradation before users notice.

Call quality is not the only per-worker record that goes stale, either: E911 dispatchable location for remote softphones needs the same periodic verification, or 911 calls route to the office address instead of the worker's home.

## The provider blame game, remote edition

When an office worker has bad call quality, the ISP and VoIP provider point fingers at each other. When a remote worker has bad call quality, add the home ISP, the home router, and the Wi-Fi to the mix. Five potential culprits, none of whom want to own the problem.

The only way to cut through this is data. If you can show that a remote worker's jitter is 8ms at the Ethernet port but 45ms after the home router, the problem is clear. If latency spikes happen on the ISP's second hop, you have something concrete to take to the provider.

Without measurement data from the remote endpoint, every troubleshooting conversation is speculation. That is why VoIP Test focuses on testing from the user's actual location, on their actual connection, under their actual conditions. The data has to come from where the problem is.

---

*For a systematic approach to finding where quality problems originate, see [How to Tell Where the Problem Actually Is](/blog/diagnosing-voip-problems) in our [VoIP From the Ground Up](/blog?category=fundamentals) series.*

---

## Wired vs. Wi-Fi for VoIP: Why the Cable Still Wins

URL: https://voiptest.com/blog/wired-vs-wifi-for-voip
Published: 2026-02-22
Category: Technical
Tags: wifi, network, voip-basics, contact-center, jitter

## The short answer

If you can run an Ethernet cable to your VoIP phone or the computer running your softphone, do it. Wired connections are more consistent, lower jitter, and eliminate an entire class of problems that Wi-Fi introduces. This has been true for years and remains true despite improvements in wireless technology.

That said, plenty of people take VoIP calls on Wi-Fi every day and it works fine. The question is not whether Wi-Fi can work. It is whether it will work reliably enough that you stop thinking about it.

## How Wi-Fi creates problems for voice

Wi-Fi operates on a shared medium. Every device connected to an access point takes turns transmitting. The protocol that manages these turns (CSMA/CA) works well enough for most traffic, but it introduces variable delays that voice traffic is particularly sensitive to.

**Contention.** When multiple devices want to transmit at the same time, they back off for random intervals and retry. The more devices on a channel, the more contention, the more variable the delays. In a busy office with 30 devices per access point, those delays add up.

**Interference.** The 2.4 GHz band is crowded. Neighboring networks, Bluetooth devices, microwave ovens, baby monitors, and wireless cameras all operate in or near this frequency range. Interference causes packet corruption and retransmission, which means jitter spikes and occasional loss.

**Signal strength variation.** Move a few feet, turn a corner, or have someone walk between you and the access point, and signal strength changes. Lower signal strength means lower modulation rates and higher error rates. This happens constantly and unpredictably.

**Channel switching and roaming.** If your device decides to switch to a different access point or channel mid-call, there is a brief disruption. Modern fast-roaming protocols (802.11r) reduce this, but many networks are not configured for them.

### The retransmissions you never see

The mechanism that does most of the damage is invisible from the IP layer, which is why Wi-Fi problems so often survive a round of network troubleshooting.

Wi-Fi retransmits at layer 2. When a frame is not acknowledged, the radio sends it again, and it will keep trying several times before giving up. From the perspective of IP, and therefore from the perspective of most diagnostic tools, nothing was lost. The packet arrived. It simply arrived late, because it took three attempts.

For a file download that is a good trade: correctness matters and a few milliseconds do not. For voice it is the wrong trade entirely, because a packet that arrives after its playout deadline is discarded by the [jitter buffer](/blog/latency-jitter-packet-loss-details) and is functionally lost anyway. Wi-Fi works hard to convert loss into delay, and voice then converts that delay straight back into loss.

This is the single best explanation for the common complaint that "the network shows no packet loss but calls sound choppy." The loss is real; it is just happening after the measurement point.

### One slow device can degrade everyone

Airtime is the resource that actually runs out, and it is shared unequally.

A device far from the access point, or behind a wall, negotiates a lower data rate. Sending the same amount of data at a lower rate takes proportionally longer, and while it transmits, nobody else on that channel can. A single laptop in a far corner on a poor link can consume a disproportionate share of the cell's airtime, and every other client, including the phone on the desk next to the access point, waits.

The counterintuitive consequence is that the device with the problem is often not the device with the symptom. Someone complains about call quality at a desk with excellent signal, and the cause is a tablet three rooms away clinging to the same access point. Airtime fairness features on better access points mitigate this, but the underlying physics does not go away.

### DFS: the failure nobody expects

This one is worth knowing because it produces a dramatic symptom with no obvious cause.

Large parts of the 5 GHz band are shared with radar: weather radar, military and aviation systems. Access points using those channels are required to listen for radar and, on detecting it, vacate the channel immediately. Not gradually, and not at a convenient moment.

When that happens, every client on that access point is moved, and any call in progress takes a hit measured in seconds rather than milliseconds. Calls drop outright. And because the trigger is an aircraft or a weather sweep rather than anything on your network, it correlates with nothing you can see in your own monitoring.

The signature is calls failing simultaneously across everyone on one access point, with no other network event to explain it, sometimes recurring at similar times of day. If that matches what you are seeing, check whether your access points are using DFS channels and pin voice-carrying radios to non-DFS channels instead.

## The numbers

The figures below are measured examples from typical office networks, not guarantees: your environment will produce its own numbers, which is why measuring beats assuming. As a representative example: baseline [jitter](/blog/what-is-jitter-and-why-it-matters) of 5 to 15ms over office Wi-Fi during business hours, with occasional spikes to 30ms or higher, against 1 to 3ms with minimal variance on a wired connection on the same network.

[Packet loss](/blog/understanding-voip-packet-loss) on a healthy Wi-Fi network might run 0.1% to 0.5% under normal conditions. That does not sound like much, but it can spike to 2% or more during interference events or heavy congestion. A functioning switch port shows near-zero loss at the access layer, though wired is not immune to congestion, because access ports still share uplinks and WAN queues, and a saturated uplink degrades wired and wireless clients alike. The wired advantage is predictability at the last hop, not exemption from the rest of the path.

These differences matter because VoIP quality degrades nonlinearly. Going from 1ms jitter to 10ms jitter is barely noticeable. Going from 10ms to 40ms (a spike that Wi-Fi produces regularly) can push packets past the playout deadline, where the jitter buffer starts discarding them.

## When Wi-Fi actually works fine

Not every VoIP scenario needs wired reliability. Wi-Fi works well enough when:

**The access point is lightly loaded.** A home office with a few devices on a modern Wi-Fi 6 access point will produce excellent results. The problems start at scale.

**The device is close to the access point with good line of sight.** Strong signal means higher modulation rates and fewer retransmissions. If your laptop sits three feet from the router, Wi-Fi jitter will be minimal.

**The 5 GHz or 6 GHz band is in use.** These bands have more available channels and less interference than 2.4 GHz. They also have shorter range, which means fewer competing devices per channel.

**The calls are internal or low-stakes.** A quick team standup is more forgiving than a sales call with a prospect. If occasional audio hiccups are acceptable, Wi-Fi is fine.

## When you need the cable

**Customer-facing calls.** If you are on the phone with clients, partners, or prospects, audio quality reflects on your business. One garbled sentence during a sales call costs more than a $5 Ethernet cable.

**Contact centers and support desks.** Covered in its own section below; this is the clearest case on the list.

**Rooms with dense device counts.** Conference rooms, trading floors, open offices with 50+ wireless devices per access point. The contention math works against you.

**Environments with known interference.** Manufacturing floors, medical facilities with wireless equipment, buildings with thick walls and lots of concrete. These create unpredictable Wi-Fi behavior.

## Contact centres are a special case

For most offices this is a judgement call. For a contact centre it is not, and the reason is arithmetic rather than preference.

An agent takes perhaps sixty calls a day. A degradation rate that a normal employee would experience as "the phone was a bit odd once last month" becomes, at that volume, several damaged customer conversations every week per agent, and they are damaged in the specific way that costs most, which is the customer having to repeat themselves to someone paid to be listening.

The environment works against you too. A contact centre floor is the worst case for every mechanism above: high device density in a small area, everyone transmitting at once, and, unlike a normal office where call volume is spread thin, everyone doing it *simultaneously*, because agents are all on calls during the same peak hours. The contention curve and the business's busiest hour are the same curve.

Add headsets. Many wireless headsets use 2.4 GHz DECT or Bluetooth, putting more radio traffic into the same space as the Wi-Fi carrying the calls.

There is also a quieter operational cost. On a wired floor, "my audio is bad" is a fault you can investigate: the path is deterministic and the variables are few. On a wireless floor it may be the agent's position, their neighbour's laptop, a roaming event, or interference that stopped ten minutes ago. Wireless does not just add call quality risk; it adds a category of problem that is expensive to diagnose and easy to fail to reproduce.

If the floor is already wireless and recabling is not on the table, the mitigations below all still apply, but measure before and after rather than assuming. And if you are sizing a new floor, cabling desks is one of the cheapest decisions in the whole build.

## Does Wi-Fi 6 change the answer?

Partly, and it is worth being precise about which part, because "we're on Wi-Fi 6 now" gets offered as a reason not to cable.

Wi-Fi 6 attacks contention directly. OFDMA lets an access point split a transmission among several clients at once instead of making each wait its turn, which suits voice unusually well: voice is many small packets from many devices, which is precisely the pattern that suffered most under the older take-turns model. Target Wake Time also reduces the power-save penalty that used to add latency after each idle period. Both are real improvements, and a modern Wi-Fi 6 or 6E deployment genuinely is better for voice than the equipment it replaced.

What it does not do is make the medium deterministic. Interference is still interference. Signal still varies as people move. Roaming still has a gap. DFS still relocates you when radar appears. And 6E's extra spectrum helps only where both the access points and the client devices support it, which on a floor of mixed-age handsets and laptops is rarely all of them.

The honest summary: Wi-Fi 6 raises the floor and narrows the gap. It does not close it, and it does not turn a shared medium into a dedicated one.

## Making Wi-Fi work better for VoIP

If running cables is genuinely impractical, these steps help:

**Dedicate an SSID for VoIP** with [WMM (Wi-Fi Multimedia) prioritization](/blog/quality-of-service-explained) enabled. WMM gives voice-classified traffic priority over background traffic. Most enterprise access points support this.

**Use the 5 GHz band** and set your VoIP devices to prefer it. Band steering on the access point helps with this. The 5 GHz band has more non-overlapping channels and less interference.

**Reduce access point density problems** by adding more access points at lower power rather than fewer at high power. Each AP serves fewer clients, reducing contention.

**Disable power save mode** on devices used for VoIP. Power save mode causes the wireless radio to sleep and wake in cycles, which adds latency to the first packet after a sleep interval.

**Keep firmware updated** on your access points. Wi-Fi driver and firmware bugs are common and often cause the kind of intermittent issues that are hard to diagnose.

## The real-world test

The best way to know if your Wi-Fi is good enough for VoIP is to test it under realistic conditions. Not at 6 AM when the office is empty, but during the afternoon when everyone is on video calls and syncing files. Jitter and loss that stay within acceptable ranges during peak load mean your wireless setup can handle voice traffic. Numbers that spike tell you where the ceiling is.

That is the kind of test our [VoIP quality test](/tools/voip-test) is designed for. Real traffic patterns, measured over meaningful time periods, during the conditions that actually matter. Run it once from a wired machine and once over Wi-Fi from the same desk and compare the jitter numbers side by side.

---

*For a complete look at how your local network affects VoIP quality, see [Your Local Network: The Part You Control](/blog/your-local-network) in our [VoIP From the Ground Up](/blog?category=fundamentals) series.*

---

## MOS Scores Explained: The Number Behind Call Quality

URL: https://voiptest.com/blog/understanding-mos-scores
Published: 2026-02-05
Category: Guides
Tags: mos-score, voip-basics, call-quality

## What MOS stands for

MOS is Mean Opinion Score. It grew out of the CCITT's (now ITU-T's) subjective testing work, formalized as the P.800 recommendation in 1996, as a way to quantify how humans perceive voice quality. The original method was simple: a group of listeners rated audio samples against P.800's five categories, and the average was the MOS.

- **5**: Excellent. Like listening in the same room.
- **4**: Good. Minor imperfections, but natural sounding.
- **3**: Fair. Noticeable distortion or effort required to understand.
- **2**: Poor. Difficult to understand.
- **1**: Bad. Unusable.

Getting a panel of listeners together every time you want to test a call is obviously impractical. So the industry developed algorithmic models that predict what a human panel would score.

## How modern MOS is calculated

Today, MOS is almost always computed by an algorithm rather than by human listeners. The two main families of approaches are:

**PESQ (Perceptual Evaluation of Speech Quality, ITU-T P.862)** compares the original audio signal to what came out the other end. It literally measures how much the audio was degraded. This is called an "intrusive" or "full-reference" method because it needs the original signal for comparison. PESQ is accurate but requires access to both sides of the conversation, which makes it impractical for live monitoring.

**POLQA (Perceptual Objective Listening Quality Analysis, ITU-T P.863)** is the successor to PESQ, designed for HD voice and modern codecs. Same basic idea: compare input to output. Higher accuracy with wideband and super-wideband audio.

**E-model ([ITU-T G.107](https://www.itu.int/rec/T-REC-G.107/en))** takes a different approach. Instead of analyzing the audio itself, it is a transmission-planning model that calculates expected conversational quality from network and codec impairments: one-way delay, packet loss, and an equipment impairment factor for the codec. Jitter is not a direct E-model input: it enters through the jitter buffer, as extra delay and as late packets discarded past the playout deadline. The E-model outputs an "R-factor" that theoretically ranges from 0 to 100, though the narrowband practical maximum is around 93-94. The R-factor maps to an estimated MOS. This is the method most monitoring tools use because it works with just network metrics and does not need the original audio.

These outputs [carry different labels for a reason](https://www.itu.int/rec/T-REC-P.800.1/en). A P.800 panel score is MOS-LQS (subjective listening quality), PESQ and POLQA produce MOS-LQO (objective listening-quality predictions), and the E-model's mapped score is MOS-CQE (estimated conversational quality). They are related but not interchangeable: a POLQA score and an E-model estimate for the same call measure different things and should not be compared as if they were the same number.

## What the numbers mean in practice

Nobody gets a MOS of 5 on a real VoIP call. The codec alone introduces some degradation, so even a perfect network path tops out around 4.4 with common codecs like G.711. Here is a more realistic interpretation:

- **4.0 to 4.4**: Excellent. Users are satisfied. This is the target for business VoIP.
- **3.6 to 4.0**: Good. Occasional minor artifacts. Most users will not complain.
- **3.1 to 3.6**: Acceptable for some use cases. Customer-facing calls will generate complaints.
- **2.6 to 3.1**: Poor. Communication is strained. Users will actively seek alternatives.
- **Below 2.6**: Not viable for business use.

The important thing is that MOS is not linear. The difference between 4.0 and 3.5 is much more noticeable than the difference between 4.4 and 4.0. Small drops in the middle of the scale represent significant degradation in the listener's experience.

## The codec ceiling

Every codec has a maximum MOS it can achieve even under perfect conditions. This is because [compression always removes some information](/blog/how-codecs-shape-call-quality) from the audio signal.

**G.711** (the traditional PSTN codec, PCM with mu-law/A-law companding): Up to 4.4. This is the baseline for toll quality. It uses 64 kbps of bandwidth per direction.

**G.729** (compressed, low bandwidth): Up to 3.9. Popular on bandwidth-constrained links because it only uses about 8 kbps. The tradeoff is that quality ceiling.

**Opus** (modern, adaptive): Up to about 4.5 at higher bitrates, which is the ceiling of the estimated-MOS scale itself. Compare that number with the two above carefully, though: the G.711 and G.729 ceilings are narrowband figures, while Opus is normally run as wideband or fullband audio, and narrowband and wideband scores are separate scales rather than points on one ladder. Opus can adjust its bitrate and complexity on the fly, which makes it excellent for variable network conditions. Most browser-based calling platforms use Opus.

If your monitoring shows a MOS of 3.9 and you are using G.729, you are actually at the codec's theoretical best. [Switching to G.711 or Opus](/blog/g711-vs-opus-vs-g722) would raise the ceiling. But if you see 3.9 on G.711, something in the network is pulling quality down.

## Network factors that lower MOS

The E-model gives us a clear picture of how each network issue impacts the score:

**[Packet loss](/blog/understanding-voip-packet-loss)** has the largest impact per percentage point, but how large depends on the codec and on whether it conceals the packets it loses. Worked through the E-model, 1% random loss costs G.711 with packet loss concealment less than 0.1 MOS, while the same 1% on G.711 without concealment costs closer to 0.5. At 3% random loss, G.711 with concealment still lands around 4.1, where a low-rate codec like G.729 is down near 3.6. Bursty loss (several packets in a row) is worse than random loss at the same percentage because the jitter buffer cannot conceal gaps that long.

**Latency** has a gradual effect. [One-way mouth-to-ear delay under 150ms](https://www.itu.int/rec/T-REC-G.114/en) is generally fine: that is the point below which interactivity is essentially transparent. Between 150ms and 400ms, conversations start to feel awkward because of the delay in responses, and 400ms is the ceiling for general network planning. Above that, people start talking over each other. The MOS impact is moderate compared to packet loss, but the conversational impact is real.

**[Jitter](/blog/what-is-jitter-and-why-it-matters)** primarily affects MOS through its interaction with the jitter buffer. High jitter that exceeds the buffer creates effective packet loss. The jitter buffer itself adds latency. So high jitter forces a tradeoff: increase the buffer (more latency) or accept more discarded packets (lower quality).

## Why a single number is both useful and dangerous

MOS gives you a single number to track, trend, and alert on. That is its strength. You can set a threshold (say, 3.8) and get notified when quality drops below it; our guide to [monitoring MOS proactively](/blog/msp-proactive-monitoring) covers where to put those thresholds so the alert fires before users complain. You can compare quality across locations, providers, or time periods.

The danger is in treating it as the whole story. A MOS of 3.8 caused by high latency is a very different problem from a MOS of 3.8 caused by packet loss. The user experience differs, the troubleshooting differs, and the fix differs. MOS tells you something is wrong. It does not tell you what.

This is why good [VoIP monitoring](/blog/voip-quality-for-remote-teams) always presents MOS alongside the underlying metrics. The score is a summary. The details are in the latency, jitter, and packet loss numbers that feed into it.

## How we use MOS at VoIP Test

When we test your connection with our [VoIP quality test](/tools/voip-test), we measure the raw network conditions (packet loss, jitter, latency) and run them through the E-model to produce a MOS estimate, with measured jitter first translated into the buffer delay and late-discard loss it would cause, since G.107 does not take jitter directly. But we also show you the breakdown so you can see exactly which factor is pulling your score down. A single number is a starting point. The underlying data is where the answers live.

---

*For a detailed look at the three metrics that feed into MOS, see [Latency, Jitter, and Packet Loss: The Details](/blog/latency-jitter-packet-loss-details) in our [VoIP From the Ground Up](/blog?category=fundamentals) series.*

---

## What Is Jitter and Why Does It Wreck Your Calls?

URL: https://voiptest.com/blog/what-is-jitter-and-why-it-matters
Published: 2026-01-18
Category: Guides
Tags: jitter, voip-basics, call-quality

## The basics

Your internet connection has a speed number attached to it. Maybe 100 Mbps down, 20 up. That number tells you how much data can flow through the pipe, but it says almost nothing about how consistently that data arrives. Jitter is the measure of that consistency.

When you send VoIP packets across a network, each one takes its own path and arrives at its own pace. In a perfect world, if you send a packet every 20 milliseconds, they arrive every 20 milliseconds. In reality, one packet might take 30ms, the next 15ms, the next 45ms. The variation between those arrival times is jitter.

## Why voice traffic hates jitter

Most internet traffic handles jitter just fine. When you load a web page, it does not matter if some packets arrive a few milliseconds late. The browser assembles everything and renders the page once it has all the pieces.

Voice is different. It plays back in real time. Your phone or softphone has a jitter buffer that collects incoming packets and reorders them before playing the audio. The buffer adds a small amount of delay (usually 20 to 60 milliseconds) to smooth things out.

When jitter stays within the buffer's window, you hear clean audio. When a packet arrives too late for the buffer to use it, it gets discarded. The effect is identical to [packet loss](/blog/understanding-voip-packet-loss): gaps, clicks, or robotic audio. High jitter effectively creates packet loss even when every packet technically arrives.

## How to read jitter numbers

Jitter is reported in milliseconds: usually the RTP interarrival jitter estimator defined in RFC 3550, which is a smoothed statistical estimate rather than a per-packet guarantee. No standard defines pass/fail jitter bands; the audible effect depends on the codec, the endpoint, and how the jitter buffer absorbs the variation. Still, as operating guidance these bands are a useful starting point:

- **Under 15ms**: Excellent. No perceptible impact on [call quality](/blog/understanding-mos-scores).
- **15 to 30ms**: Acceptable. A well-tuned jitter buffer handles this without issue.
- **30 to 50ms**: Degraded. You will start hearing artifacts, especially with smaller buffer sizes.
- **Over 50ms**: Poor. Expect frequent audio problems regardless of buffer configuration.

These are operating targets, not standards guarantees, and they assume a properly configured jitter buffer. A misconfigured buffer can make 20ms jitter sound terrible, while a generous buffer can paper over 40ms jitter at the cost of added latency.

## Common causes

**Network congestion** is the usual suspect. When a router gets overloaded, it queues packets. Some wait longer than others, and that inconsistency is jitter. This is why call quality often degrades during business hours when everyone is on video calls and pulling files from the cloud.

**[Wi-Fi](/blog/wired-vs-wifi-for-voip)** adds jitter by nature. The wireless medium is shared, and devices take turns transmitting. Interference from other access points, Bluetooth devices, or even microwaves introduces unpredictable delays. If you are running VoIP over Wi-Fi, expect higher baseline jitter than on a wired connection.

**Long or complex routes** contribute as well. If your packets are bouncing through a dozen hops across multiple ISP networks, each hop introduces a small amount of variability. International calls routed through multiple carriers tend to have higher jitter than local traffic.

**Bufferbloat** is an often-overlooked cause. Some routers and modems have oversized buffers that create large, variable queuing delays. The connection still shows low packet loss, but jitter spikes dramatically under load. The fix is usually enabling SQM (Smart Queue Management) or similar QoS on your router.

## Jitter vs. latency

People sometimes confuse the two. Latency is how long it takes a packet to get from point A to point B. Jitter is how much that time varies from packet to packet.

You can have high latency with low jitter. A satellite link might have 600ms of latency, but if every packet takes almost exactly 600ms, the jitter is low. The call will have a noticeable delay, but the audio itself will be clear.

You can also have low latency with high jitter. A local network might average 5ms latency, but if packets bounce between 2ms and 40ms, the jitter is terrible and calls will sound broken.

For voice quality, consistent delivery matters more than fast delivery. A steady 80ms connection produces better calls than an erratic 20ms connection.

## What you can do

**Use wired connections** for VoIP endpoints whenever possible. This is the single most impactful change for most setups.

**Enable [QoS](/blog/quality-of-service-explained)** on your router to prioritize voice traffic. DSCP marking (EF/46 for voice) tells network equipment to handle voice packets with priority. This helps most during congestion.

**Check for bufferbloat** using a DSLReports or Waveform speed test. If your bufferbloat grade is poor, enable SQM on your router. OpenWrt-based routers support this natively. Many consumer routers now include it as "QoS" or "traffic management."

**Right-size your jitter buffer** if your VoIP system exposes this setting. Too small and you lose packets unnecessarily. Too large and you add latency that makes conversation awkward. Most systems auto-tune this, but manual settings can help in consistently high-jitter environments.

**Separate your traffic** with VLANs if you manage your own network. A VLAN by itself is segmentation, not scheduling (it does not reserve bandwidth or create a queue), but putting voice on its own VLAN makes it easy to classify and apply QoS consistently, which is what actually protects the voice path from bulk transfers.

## The testing gap

Standard speed tests tell you bandwidth and average latency. They do not measure jitter in a way that reflects VoIP performance, because they use TCP (which retransmits lost data) rather than UDP (which mirrors real voice traffic). To actually know your jitter characteristics under realistic conditions, you need a test that simulates voice packet patterns, which is exactly what our [VoIP quality test](/tools/voip-test) does.

---

*For a deeper look at how jitter fits into the full voice path alongside latency and packet loss, see [Latency, Jitter, and Packet Loss: The Details](/blog/latency-jitter-packet-loss-details) in our [VoIP From the Ground Up](/blog?category=fundamentals) series.*