What type of internet connection do I need for VoIP?

Cisco's bandwidth calculation for a call on the G.711 codec comes to 87.2 kbps. That figure assumes 20 milliseconds of audio in each packet, the IPv4, UDP and RTP headers, and Ethernet framing. A call sends and receives at the same time, and Cisco's design guidance applies the rate to each direction separately.

Twilio's SIP trunking documentation plans on 100 kbps per simultaneous call for the same codec, and says the figure includes room for overhead. The two numbers don't disagree. Cisco's is a calculated rate for one stated setup, and Twilio's is a round allowance with margin built in. Other codecs and packet settings produce other rates, which we work through in how much bandwidth a VoIP call uses. If your provider publishes a per-call figure, plan with that one.

In the table below we apply Twilio's 100 kbps allowance to upload and to download separately. That's our planning assumption, and it follows the way Cisco treats its own rate. The direction matters because many internet plans are sold with less upload than download. On a plan like that, upload is the figure to compare against your calls.

The capacity follows the number of calls you want to carry at the same time. The count of employees or phone numbers doesn't set it. Your call records are a starting point for that number. If they count only the calls that connected, a busy period in which callers were turned away will look smaller than the demand was.

Suppose a 20-person office decides to allow for eight calls at once. At 100 kbps per call in each direction, voice needs 800 kbps of upload and 800 kbps of download. Suppose the plan has 10 Mbps of upload. Voice would take 8 percent of it.

The other inputs are whatever else uses the connection at the same moment. Microsoft's network guidance for Teams recommends 1,500 kbps in each direction for a single one-to-one video call. In the example, one such call needs more upload than the eight voice calls combined. Add the office's video meetings, backups and file uploads to the voice figure, and compare the total with the upload the plan provides.

You can add a margin above that total. The margin is a planning choice, not a measured call requirement. If you're sizing a trunk for a phone system you run, we cover the call count in how many simultaneous calls you need on a SIP trunk.

The second decision is the route your calls take to the provider. Twilio's documentation lists two ways to connect a trunk: over the public internet, or over its private Interconnect service. Either one is an IP connection. They differ in who runs the network in the middle.

Atlantech Online described the same choice from a carrier's side in a July 2016 article. In the first arrangement, which it calls bring your own bandwidth, a business buys internet from one company and phone service from another. Each call leaves on the internet connection and crosses the public internet to reach the phone provider's voice switch. In the second, the office's connection sits on the same network as the voice switch. Atlantech wrote that calls on its network go from the office to its switch without crossing the internet. It also wrote that it tags voice packets for priority, which it can do because it manages the equipment at both ends.

Priority for voice works only on equipment that someone has configured to honor it. Microsoft's guidance for Teams says to set up quality of service on every segment of a managed network. A priority marking set in your office doesn't ensure that the other networks a call crosses will honor it. In the arrangement Atlantech described, the path from the office to the voice switch is under one company's management.

An ordinary internet connection from another company is still a workable choice. Atlantech's article says the bring-your-own arrangement can work well enough for a small company. Whether the provider's connection suits your office depends on the quote, on what the service covers and on what a phone outage would cost you. For a phone system you run, the same decision is covered in what kind of internet connection you need for SIP trunking.

The connection ends at your router, and the call still has to cross the office network to reach it. Microsoft's guidance says Wi-Fi networks aren't necessarily designed or configured for real-time media. It recommends planning for it, with priority for media traffic and attention to the wireless band and where the access points sit.

That's guidance for Teams, and what it asks for is planning. Wi-Fi isn't ruled out. A desk phone on a network cable doesn't depend on the wireless network. Calls from a laptop on Wi-Fi depend on how the wireless network is set up, so try calls from the places people work while the office is busy.

The headline figure on a speed test is throughput, which is how much data the connection moved during the test. A call also needs its packets to arrive steadily. The specification for RTP, the protocol that carries call audio, says RTP doesn't guarantee delivery or timely arrival and relies on the network underneath for both. So a connection with capacity to spare can still deliver voice packets late when it's busy. A receiving device can absorb a little lateness. Past that point, the listener can hear choppy or clipped speech.

Some speed tests also report jitter and packet loss, and those figures say more about calls than the throughput number does. The better test is a trial of real calls on the connection during a busy hour, before the phone numbers move. If the trial calls break up, the symptoms help narrow down where to look, and we go through them in common UCaaS call quality problems.

People who work from home add one more thing to plan. Each home connection is a separate requirement, so a strong connection at the office says nothing about theirs.