What kind of internet connection and bandwidth do I need for SIP trunking?

The size of the connection follows one number: how many calls you run at the same time during your busiest hour, not how many phones or numbers you own.[1] Each simultaneous call needs roughly 85 to 90 kilobits per second in each direction with the common G.711 codec, or about 31 kilobits per second with the more compressed G.729a, once the IP, UDP, and RTP headers are counted on top of the raw audio.[2][6] Multiply your peak concurrent calls by that per-call figure, add 10 to 20 percent of headroom for signaling and the data traffic sharing the link, and you have a floor for the connection you need.[7][8]

Start from concurrent calls, not from headsets

A business with fifty employees almost never has fifty calls in progress at once, so sizing the link to fifty calls wastes money.[1] The useful measure is the number of calls active at your busiest hour, which providers call peak concurrent call paths.[1] Count that number, size the bandwidth to it, and add a margin for growth, because a trunk lets you raise or lower channels in software without new wiring once the underlying connection has room.

Bandwidth alone does not decide call quality

Speed is only half of the requirement. Voice is sensitive to delay, timing variation, and lost packets, so a connection with plenty of megabits can still produce choppy or clipped audio if those measures drift.[5][9] A SIP-ready connection has to hold one-way latency under about 150 milliseconds, jitter under about 30 milliseconds, and packet loss under roughly 1 percent, and on most consumer lines the upload direction runs out first.[5][9] The rest of this answer covers both the sizing math and the quality targets that decide whether calls actually sound clean.

A SIP trunk needs its per-call bandwidth available in each direction at the same time, and on most connections the upload path is the one that runs out first.[9] A phone call is symmetric, since both people talk, so a call using G.711 consumes about 85 to 90 kilobits per second upstream and the same downstream.[2][9] Consumer and many business plans are asymmetric, advertising a large download figure and a much smaller upload, so the usable ceiling for concurrent calls is set by the smaller upload number.[8][9] A 50 by 10 megabit line, for instance, has room for roughly 100 G.711 calls on the upstream side before headroom, well short of what the download figure alone would suggest.[9] When you run a speed test to plan capacity, use the upload result, convert it to kilobits by multiplying the megabit figure by a thousand, then divide by your per-call bandwidth to see how many calls the link can hold.[8] Symmetric connections, where upload matches download, make SIP capacity planning far more predictable, which is part of why business fiber is the usual recommendation.[9][11]

One-way delay on a voice call should stay under about 150 milliseconds, the threshold the ITU-T sets in Recommendation G.114 for keeping a conversation feeling natural.[5][9] Below that figure, most callers perceive the exchange as immediate; between 150 and 400 milliseconds the delay becomes noticeable and people begin talking over each other, and past 400 milliseconds interactive conversation breaks down.[5][9] Latency comes from the distance packets travel and every device that handles them along the way, so a provider with points of presence near you and a direct path to the phone network matters as much as the speed of your own link.[9] You cannot buy your way past a latency problem with more megabits, because a congested or geographically distant path adds delay no matter how much raw bandwidth sits idle.[9] Testing round-trip time to your provider before you commit, then halving it for a rough one-way figure, tells you whether the path has the margin voice needs.

Jitter is the variation in how evenly voice packets arrive, and it should stay under about 30 milliseconds for calls to sound smooth.[9] Voice packets leave in an even stream fifty times a second, but a busy or poorly managed network can bunch them up and space them out, so they reach the far end at uneven intervals.[4][9] Phones and session border controllers absorb some of this with a jitter buffer that holds arriving packets briefly and releases them on a steady beat, yet a buffer only has so much room, and once jitter exceeds it the audio turns choppy or drops syllables.[9] High jitter usually points to congestion or to voice competing with bulk data on the same link rather than to a shortage of bandwidth, which is why prioritizing voice traffic addresses it more reliably than buying a bigger connection.[9] Keeping the link from saturating and marking voice as priority traffic are the two moves that hold jitter down.

Lost packets should stay under about 1 percent, because voice has no time to wait for a dropped packet to be resent.[9] A file transfer recovers a lost packet by asking for it again, but a live call has already moved on, so the audio for that missing slice is simply gone, heard as a clipped word or a brief gap.[9] Even loss around 1 percent is noticeable on a G.711 call, and more compressed codecs tolerate less before quality falls off, since each of their packets carries more of the conversation.[9] Loss tends to appear when a link saturates and a router discards packets it cannot queue, so it often arrives together with rising jitter during the busy hour.[9] Sizing the connection with headroom above your peak call bandwidth, and giving voice priority so it is not the traffic dropped under load, are what keep loss inside the tolerable range.[8][9]

Quality-of-service settings tell your network to move voice packets ahead of everything else, and on a shared connection they are the single most effective protection for call quality.[9] Voice is marked with the Expedited Forwarding class, DSCP value 46, so routers and switches recognize it and serve it before email, backups, and file downloads that can wait a few milliseconds without anyone noticing.[9] Without prioritization, a large upload or a cloud backup can fill the link and push voice packets into delay and loss precisely when calls are busiest.[9] QoS works well when you control the network end to end, which inside your own building you do, though it cannot govern the public internet between you and your provider, and that gap is one reason a dedicated or provider-supplied connection is often recommended for voice.[9][11] On a business fiber connection paired with the SIP provider, voice can be prioritized across the whole path rather than only inside your walls.[10][11]

For most businesses a symmetric, business-grade connection with quality-of-service support is the practical answer, and fiber is the common choice because it offers matching upload and download with low latency and jitter.[10][11] A dedicated internet access circuit, where the bandwidth is yours rather than shared across a neighborhood, gives the most predictable voice quality because your calls never compete with other subscribers for capacity.[9] Cable and DSL can carry SIP trunking, and many small offices run it successfully, but their asymmetric upload and shared design make capacity planning less certain, so they suit lower call volumes better than a busy call center.[8][9] Some organizations keep voice on a separate circuit or a separate VLAN from data so the two never contend, and higher-volume sites add a second connection from another provider so calls fail over if the primary link goes dark.[9] The connection you already have may be enough for a handful of concurrent calls, which is why measuring your peak call volume and testing your current upload before ordering anything new is the sensible first step.[8][11]

Sizing a connection for SIP trunking involves a few tensions worth planning around rather than discovering after cutover.

Bigger is not the same as better

Buying far more bandwidth than your call volume needs does not improve call quality once you have enough, because delay, jitter, and loss come from congestion, routing, and prioritization rather than from a shortage of raw megabits.[9] A modest link with quality of service and low latency carries voice better than a large link with neither.[9]

Compression saves bandwidth but costs fidelity

Choosing G.729a over G.711 cuts per-call bandwidth by roughly two-thirds on the wire, which helps where the upstream link is tight, though it lowers the mean opinion score and can compound with any packet loss already on the path.[1][2] Where bandwidth is comfortable, G.711 keeps audio closest to landline quality.[6]

Voice competes with your other traffic

On a single shared connection, a cloud backup, a large file upload, or a video meeting can crowd out calls at the worst moment, so either prioritizing voice or separating it onto its own circuit is what keeps the busy hour clean.[9][11]

The public internet is outside your control

Quality of service inside your building does not extend across the open internet to your provider, so latency and loss introduced along that path are only partly manageable, which is why many businesses choose a provider that also supplies the underlying connection.[9][11]

Sizing internet for SIP trunking gets confused with a few neighboring ideas, and separating them prevents over-buying or under-buying.

It is not just a download-speed question

The advertised download figure on an internet plan says little about SIP capacity, because a call needs equal room upstream and the upload number is usually the smaller of the two.[8][9] Two plans with the same download speed can hold very different numbers of calls depending on their upload.[9]

More bandwidth is not a fix for bad quality

Adding megabits does not repair latency, jitter, or packet loss that come from congestion or a distant routing path, so a quality problem calls for prioritization, a better path, or a dedicated circuit rather than a larger pipe.[9]

Signaling bandwidth is not the media bandwidth

The SIP messages that set up and tear down a call use very little bandwidth, since almost all of a call's traffic is the RTP media stream carrying the audio, which is what the per-call figures measure.[4][10] Planning around the media rather than the signaling is what matters for sizing.[4]

It is not a one-time calculation

Call volume grows, new sites come online, and codecs get changed, so the connection that fit last year may not fit today, which makes peak-hour capacity something to revisit rather than set once.[1]