The number you need is the count of calls your busiest hour runs at the same time, not the number of employees, phones, or numbers you hold, and each of those calls occupies one channel, or SIP session, on the trunk.[1][5] A common starting point for a general office is one channel for every three to four employees, while a contact center needs closer to one channel per active agent, but the accurate way to size it is to feed your busy-hour call volume and average call length into an Erlang B calculation at a one percent blocking target.[4][5][2][3] The number you actually get is not fixed by the trunk itself: capacity is limited by your internet bandwidth, your codec, and any per-plan cap your provider sets, since each concurrent call consumes roughly 80 to 115 kilobits per second once packet overhead is counted.[6][7][5] As a rough ceiling, a clean 2 megabit connection carries about 25 G.711 calls, and providers can raise or lower your channel count in software rather than installing new circuits.[6][4][11]
\n","summary":"Simultaneous calls on a SIP trunk are counted in channels, one call per channel. Size the number you need from busy-hour concurrency, not headcount: a rough office baseline is one channel per three to four employees, a contact center closer to one per agent, and Erlang B gives the precise figure at a set blocking target. The number you can get is capped by bandwidth, codec, and your provider's plan, with each call using about 80 to 115 kbps and channels adjustable in software.","publishedAt":"2026-07-18T15:16:53.422","verifiedAt":"2026-07-18T00:00:00","editorialStatus":"APPROVED","lastReviewedAt":"2026-07-18T00:00:00","nextReviewDueAt":"2026-10-18T00:00:00","templateVersion":"v2","aliases":["How many channels do I need on a SIP trunk?","How many concurrent calls can a SIP trunk handle?","How many simultaneous calls does a SIP trunk support?","SIP trunk channel calculator","How to size a SIP trunk","How many SIP channels per employee?","SIP trunk concurrent call limit","How many SIP trunks do I need?","SIP trunk capacity planning","Erlang B SIP trunk sizing","Channels vs concurrent calls on a SIP trunk","How many calls at once on a SIP trunk?"],"confidenceScore":88,"confidenceLabel":"High","canonicalUrl":null},"contributor":{"id":"ec39deab-44fe-48d8-9029-fefe993ab85a","slug":"answer-stack","displayName":"AnswerStack","websiteUrl":null},"contributorOrganizationProfile":{"entityId":"ec39deab-44fe-48d8-9029-fefe993ab85a","legalName":null,"description":null,"websiteUrl":null,"imageUrl":null,"slogan":null,"subtitle":null,"facts":[],"coiNote":null,"foundingDate":null,"numberOfEmployeesText":null,"contactPoint":null,"address":null,"headquartersText":null,"organizationType":null},"contributorPerson":{"slug":"answerstack-editorial-team","displayName":"AnswerStack Editorial Team"},"sections":[{"id":"358eea1e-fd0b-4b8d-ad74-bb1fb126f5c9","sectionKey":"explainer","sectionType":"markdown_section","heading":"How many simultaneous calls does a SIP trunk need or provide?","introMarkdown":"Simultaneous calls on a SIP trunk are measured in channels, also called concurrent call paths or sessions, and one channel carries exactly one call at a time.[1][5] The question really has two sides that are easy to run together. One side is how many concurrent calls you need, which is a sizing problem driven by how many calls your organization runs at the same moment during its busiest hour. The other side is how many you can get, which is a capacity problem set by your internet bandwidth, your audio codec, and whatever channel limit your provider attaches to your plan.[6][7] A well planned trunk lines those two numbers up, with the capacity you buy sitting a comfortable margin above the concurrency you actually use.\n\nThe count that matters for sizing is simultaneous calls, not the number of employees, desk phones, or phone numbers you hold.[5][9] A fifty person office almost never has fifty people talking at once, so buying fifty channels wastes money, while a ten seat outbound sales team can run near ten calls continuously and needs close to that many. Direct inward dial numbers are separate again, because you can point hundreds of numbers at a trunk that only carries a dozen concurrent calls, since most of those numbers sit idle at any given second.[5]\n\n### Why the old line-counting habit does not transfer\n\nOn a legacy PRI circuit, capacity arrived in a fixed block of physical channels, and adding calls beyond that block meant installing another circuit.[9][11] A SIP trunk removes that hardware step, so capacity becomes a number your provider sets in software and bills per channel or per minute.[11][4] That flexibility is useful, yet it shifts the work onto you to pick the right number, because there is no physical circuit forcing the decision. The rest of this answer covers how to calculate the number you need, then what caps the number you can actually run.","introHtml":"Simultaneous calls on a SIP trunk are measured in channels, also called concurrent call paths or sessions, and one channel carries exactly one call at a time.[1][5] The question really has two sides that are easy to run together. One side is how many concurrent calls you need, which is a sizing problem driven by how many calls your organization runs at the same moment during its busiest hour. The other side is how many you can get, which is a capacity problem set by your internet bandwidth, your audio codec, and whatever channel limit your provider attaches to your plan.[6][7] A well planned trunk lines those two numbers up, with the capacity you buy sitting a comfortable margin above the concurrency you actually use.
\nThe count that matters for sizing is simultaneous calls, not the number of employees, desk phones, or phone numbers you hold.[5][9] A fifty person office almost never has fifty people talking at once, so buying fifty channels wastes money, while a ten seat outbound sales team can run near ten calls continuously and needs close to that many. Direct inward dial numbers are separate again, because you can point hundreds of numbers at a trunk that only carries a dozen concurrent calls, since most of those numbers sit idle at any given second.[5]
\nOn a legacy PRI circuit, capacity arrived in a fixed block of physical channels, and adding calls beyond that block meant installing another circuit.[9][11] A SIP trunk removes that hardware step, so capacity becomes a number your provider sets in software and bills per channel or per minute.[11][4] That flexibility is useful, yet it shifts the work onto you to pick the right number, because there is no physical circuit forcing the decision. The rest of this answer covers how to calculate the number you need, then what caps the number you can actually run.
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":0},{"id":"f625b964-5bd9-44d1-922b-40ca8b8ad42f","sectionKey":"sizing_methods_table","sectionType":"table_section","heading":"How do you calculate the number of channels you need?","introMarkdown":"Three methods size a SIP trunk, and they trade speed for accuracy.[4][2] The quick ratio method estimates channels from headcount, the concurrency method scales headcount by how much of your team is actually on calls at peak, and the Erlang B method uses real busy-hour traffic to hit a chosen blocking target.[4][7][2] The table sets them side by side, and the sections after it work through each one with the inputs it needs and where it fits.","introHtml":"Three methods size a SIP trunk, and they trade speed for accuracy.[4][2] The quick ratio method estimates channels from headcount, the concurrency method scales headcount by how much of your team is actually on calls at peak, and the Erlang B method uses real busy-hour traffic to hit a chosen blocking target.[4][7][2] The table sets them side by side, and the sections after it work through each one with the inputs it needs and where it fits.
\n","outroMarkdown":"None of the three is a substitute for watching real usage once the trunk is live, since the right number is the one your busy-hour data confirms after a few weeks of calls.[4]","outroHtml":"None of the three is a substitute for watching real usage once the trunk is live, since the right number is the one your busy-hour data confirms after a few weeks of calls.[4]
\n","contentJson":{"rows":[{"cells":["Quick ratio","Employee count and a rule-of-thumb divisor [5]","Small offices and fast first estimates [5]"]},{"cells":["Concurrency percentage","External call users and a peak concurrency rate [7]","Teams whose call habits differ from the office average [7]"]},{"cells":["Erlang B traffic model","Busy-hour call volume, average call length, target blocking [2][3]","Contact centers and any capacity you cannot afford to under-buy [2]"]}],"columns":["Method","Inputs it needs","Best for"]},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":1},{"id":"ed1647c1-7c7c-4161-ac1b-5cfa00f4b244","sectionKey":"ratio_method","sectionType":"markdown_section","heading":"The quick ratio method","introMarkdown":"The ratio method divides your headcount by a rule-of-thumb figure to get a channel estimate, and it works because most people are not on the phone at the same time.[5] For a general office, a common baseline is one channel for every three to four employees, which assumes a mix of calls, email, and meetings across the day.[5][4] A ten person office lands around three channels on that math, and a fifty person office around thirteen to seventeen.[4] Contact centers break the ratio, because agents are on calls for most of their shift, so the planning figure moves close to one channel per active agent, and outbound teams that dial continuously sometimes need more than one.[4][8]\n\nThe appeal of this method is that it takes a minute and needs no call data, which makes it a reasonable first pass for a small, predictable office. Its weakness is that a single divisor cannot know your actual call profile, so a busy inside sales team sized at one channel per four people will hit its ceiling and start blocking calls at peak. Treat the ratio as a starting estimate you refine against real numbers, rather than the final count you buy.","introHtml":"The ratio method divides your headcount by a rule-of-thumb figure to get a channel estimate, and it works because most people are not on the phone at the same time.[5] For a general office, a common baseline is one channel for every three to four employees, which assumes a mix of calls, email, and meetings across the day.[5][4] A ten person office lands around three channels on that math, and a fifty person office around thirteen to seventeen.[4] Contact centers break the ratio, because agents are on calls for most of their shift, so the planning figure moves close to one channel per active agent, and outbound teams that dial continuously sometimes need more than one.[4][8]
\nThe appeal of this method is that it takes a minute and needs no call data, which makes it a reasonable first pass for a small, predictable office. Its weakness is that a single divisor cannot know your actual call profile, so a busy inside sales team sized at one channel per four people will hit its ceiling and start blocking calls at peak. Treat the ratio as a starting estimate you refine against real numbers, rather than the final count you buy.
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":2},{"id":"e8922e5e-beaf-4949-9e0a-3fbbe8564ff2","sectionKey":"concurrency_method","sectionType":"markdown_section","heading":"The concurrency-percentage method","introMarkdown":"This method multiplies the number of people who make external calls by the share of them on a call at your busiest moment, which produces a concurrency estimate tuned to how your team actually works.[7] The formula is short: estimated concurrent calls equals peak utilization percentage times the number of external call users.[7] What gives the approach its value is the peak utilization figure, because it forces you to describe your own call pattern instead of borrowing an office average.\n\nPublished benchmarks give a sense of the spread. Retail or sales call centers often run 40 to 60 percent of seats on calls at once, technical or SaaS support teams tend to land somewhere around 15 to 30 percent, and a law firm or similar professional office may sit at 10 to 20 percent.[7] A forty person support team at 25 percent peak concurrency needs about ten channels, a number a flat office ratio could miss in either direction depending on the divisor you picked. Where you already have history from your phone system or provider, use your own measured peak rather than a benchmark, since the benchmark is only a stand-in until you have the real figure.","introHtml":"This method multiplies the number of people who make external calls by the share of them on a call at your busiest moment, which produces a concurrency estimate tuned to how your team actually works.[7] The formula is short: estimated concurrent calls equals peak utilization percentage times the number of external call users.[7] What gives the approach its value is the peak utilization figure, because it forces you to describe your own call pattern instead of borrowing an office average.
\nPublished benchmarks give a sense of the spread. Retail or sales call centers often run 40 to 60 percent of seats on calls at once, technical or SaaS support teams tend to land somewhere around 15 to 30 percent, and a law firm or similar professional office may sit at 10 to 20 percent.[7] A forty person support team at 25 percent peak concurrency needs about ten channels, a number a flat office ratio could miss in either direction depending on the divisor you picked. Where you already have history from your phone system or provider, use your own measured peak rather than a benchmark, since the benchmark is only a stand-in until you have the real figure.
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":3},{"id":"d26194b9-4395-4dc9-9cdc-dd8e3bcc59c1","sectionKey":"erlang_b_method","sectionType":"markdown_section","heading":"The Erlang B method for busy-hour traffic","introMarkdown":"Erlang B is the traffic-engineering model built for exactly this question, and it converts your busy-hour calling into the number of channels required to keep blocked calls below a target you set.[2][3] It fits trunk sizing because a SIP trunk clears a blocked call rather than queuing it: when every channel is busy, the next caller gets a busy signal, which is the assumption the model is built on.[3] Erlang C is the related model for agent queues where callers wait on hold, so it sizes staff rather than trunks.[3]\n\n### The inputs and the formula\n\nThe model needs your busy-hour traffic in a unit called the Erlang and your target blocking rate, and it returns the channel count.[2] Busy-hour traffic reduces to a single number: calls per hour times average call duration in seconds, divided by 3,600.[2][3] A site handling 350 calls an hour at 180 seconds each carries 17.5 Erlangs of traffic.[2] Feed that into an Erlang B calculator at one percent blocking, the normal target in traffic engineering, and the answer is 27 channels, while a more relaxed three percent target needs fewer.[2] A smaller case lands the same way: 120 busy-hour calls at three minutes each is 6 Erlangs, which needs about 11 channels at one percent blocking.[4]\n\n### Why the precise method is worth it\n\nThe Erlang calculation earns its keep where under-buying has a real cost, such as a contact center that loses revenue on every blocked call, because it ties the channel count to a defined service level instead of a guess.[2] For a small office the ratio method usually lands close enough. Once call volume climbs or turns spiky, the traffic model becomes the difference between paying for idle channels and turning callers away at the peak.","introHtml":"Erlang B is the traffic-engineering model built for exactly this question, and it converts your busy-hour calling into the number of channels required to keep blocked calls below a target you set.[2][3] It fits trunk sizing because a SIP trunk clears a blocked call rather than queuing it: when every channel is busy, the next caller gets a busy signal, which is the assumption the model is built on.[3] Erlang C is the related model for agent queues where callers wait on hold, so it sizes staff rather than trunks.[3]
\nThe model needs your busy-hour traffic in a unit called the Erlang and your target blocking rate, and it returns the channel count.[2] Busy-hour traffic reduces to a single number: calls per hour times average call duration in seconds, divided by 3,600.[2][3] A site handling 350 calls an hour at 180 seconds each carries 17.5 Erlangs of traffic.[2] Feed that into an Erlang B calculator at one percent blocking, the normal target in traffic engineering, and the answer is 27 channels, while a more relaxed three percent target needs fewer.[2] A smaller case lands the same way: 120 busy-hour calls at three minutes each is 6 Erlangs, which needs about 11 channels at one percent blocking.[4]
\nThe Erlang calculation earns its keep where under-buying has a real cost, such as a contact center that loses revenue on every blocked call, because it ties the channel count to a defined service level instead of a guess.[2] For a small office the ratio method usually lands close enough. Once call volume climbs or turns spiky, the traffic model becomes the difference between paying for idle channels and turning callers away at the peak.
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":4},{"id":"d8c86c08-dd06-4590-9523-5de4c5790060","sectionKey":"capacity_ceiling","sectionType":"markdown_section","heading":"How many simultaneous calls can a SIP trunk actually carry?","introMarkdown":"There is no single fixed number, because a SIP trunk's ceiling is set by your bandwidth, your codec, and any cap your provider places on the plan, not by the trunk itself.[6][7] In practice a standard business trunk is often provisioned for something like 20 to 25 concurrent calls, a high-capacity trunk for up to around 100, and some cloud providers sell trunks with no hard channel cap at all, letting bandwidth be the only limit.[6] The figure you can actually sustain comes down to a few factors worth understanding separately.\n\n### Bandwidth is the hard physical limit\n\nEvery concurrent call consumes a slice of your internet connection, so the usable ceiling is your available voice bandwidth divided by the bandwidth per call.[6][9] With the common G.711 codec, each call needs roughly 80 to 90 kilobits per second once IP, UDP, and RTP overhead sits on top of the 64 kilobit payload, and one provider guide puts the practical range at 85 to 115 kilobits depending on codec.[9][10][5] A clean 2 megabit link therefore carries about 25 simultaneous G.711 calls, and the same arithmetic scales up from there.[6]\n\n### The codec changes the number sharply\n\nSwapping codecs moves the ceiling a long way, because a more compressed codec fits more calls into the same pipe.[7] G.711 sends uncompressed audio at 64 kilobits and gives the best fidelity, while G.729 compresses to roughly 8 to 24 kilobits and Opus adapts across a similar low range, at some cost to quality.[10][6][7] A 10 megabit connection that holds around 50 G.711 calls can carry closer to 100 with G.729, which is why codec choice is a capacity decision and not only a quality one.[6][7]\n\n### The provider plan sets a soft cap\n\nAbove the physical limit, most providers attach a channel cap to your subscription, an administrative ceiling that restricts concurrency regardless of how much bandwidth you have.[7] Because that cap lives in software, a provider can raise or lower it on request, often the same day, which is how seasonal peaks get handled without new hardware.[11][9] Confirm both numbers when you buy, the channels your plan permits and the bandwidth your connection can actually sustain, since the smaller of the two is your real ceiling.\n\n### Your own network can cap it too\n\nYour network configuration adds its own limits, so a trunk rated for hundreds of calls still stops at whatever your firewall, session border controller, or phone system is set to allow.[6][7] On larger deployments this is worth checking, because the bottleneck is sometimes local equipment rather than the trunk or the circuit.","introHtml":"There is no single fixed number, because a SIP trunk's ceiling is set by your bandwidth, your codec, and any cap your provider places on the plan, not by the trunk itself.[6][7] In practice a standard business trunk is often provisioned for something like 20 to 25 concurrent calls, a high-capacity trunk for up to around 100, and some cloud providers sell trunks with no hard channel cap at all, letting bandwidth be the only limit.[6] The figure you can actually sustain comes down to a few factors worth understanding separately.
\nEvery concurrent call consumes a slice of your internet connection, so the usable ceiling is your available voice bandwidth divided by the bandwidth per call.[6][9] With the common G.711 codec, each call needs roughly 80 to 90 kilobits per second once IP, UDP, and RTP overhead sits on top of the 64 kilobit payload, and one provider guide puts the practical range at 85 to 115 kilobits depending on codec.[9][10][5] A clean 2 megabit link therefore carries about 25 simultaneous G.711 calls, and the same arithmetic scales up from there.[6]
\nSwapping codecs moves the ceiling a long way, because a more compressed codec fits more calls into the same pipe.[7] G.711 sends uncompressed audio at 64 kilobits and gives the best fidelity, while G.729 compresses to roughly 8 to 24 kilobits and Opus adapts across a similar low range, at some cost to quality.[10][6][7] A 10 megabit connection that holds around 50 G.711 calls can carry closer to 100 with G.729, which is why codec choice is a capacity decision and not only a quality one.[6][7]
\nAbove the physical limit, most providers attach a channel cap to your subscription, an administrative ceiling that restricts concurrency regardless of how much bandwidth you have.[7] Because that cap lives in software, a provider can raise or lower it on request, often the same day, which is how seasonal peaks get handled without new hardware.[11][9] Confirm both numbers when you buy, the channels your plan permits and the bandwidth your connection can actually sustain, since the smaller of the two is your real ceiling.
\nYour network configuration adds its own limits, so a trunk rated for hundreds of calls still stops at whatever your firewall, session border controller, or phone system is set to allow.[6][7] On larger deployments this is worth checking, because the bottleneck is sometimes local equipment rather than the trunk or the circuit.
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":5},{"id":"d3966bbb-c148-43b9-a225-0c036631d121","sectionKey":"contributor_perspective","sectionType":"markdown_section","heading":"How this answer was researched","introMarkdown":"This entry separates two questions that often get merged: how many simultaneous calls to buy, and how many a trunk can carry. The sizing methods are attributed to independent telecom and provider sources, and the traffic-engineering claims come from the Erlang B model as documented by traffic-engineering references rather than any single vendor.[2][3][4] Bandwidth-per-call and codec figures are drawn from several provider guides and the ITU-T codec standard, so no one commercial page is the sole basis for a number.[5][6][9][10] Pricing, plan caps, and channel practices vary by provider and shift over time, so the figures here reflect what the cited sources stated on the verification date rather than fixed rules. Practitioners who provision or troubleshoot SIP trunks are welcome to suggest corrections or additions, which are checked against primary sources before any update.","introHtml":"This entry separates two questions that often get merged: how many simultaneous calls to buy, and how many a trunk can carry. The sizing methods are attributed to independent telecom and provider sources, and the traffic-engineering claims come from the Erlang B model as documented by traffic-engineering references rather than any single vendor.[2][3][4] Bandwidth-per-call and codec figures are drawn from several provider guides and the ITU-T codec standard, so no one commercial page is the sole basis for a number.[5][6][9][10] Pricing, plan caps, and channel practices vary by provider and shift over time, so the figures here reflect what the cited sources stated on the verification date rather than fixed rules. Practitioners who provision or troubleshoot SIP trunks are welcome to suggest corrections or additions, which are checked against primary sources before any update.
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":"This answer was written and reviewed by the AnswerStack Editorial Team, which has no commercial stake in the products, companies, or methods discussed. Every claim is cited inline and verified on the dates shown.","noteHtml":"This answer was written and reviewed by the AnswerStack Editorial Team, which has no commercial stake in the products, companies, or methods discussed. Every claim is cited inline and verified on the dates shown.
\n","sortOrder":6},{"id":"2c04a330-e4e1-43c3-b7e1-d08c20e32ecf","sectionKey":"trade_offs","sectionType":"markdown_section","heading":"Trade-offs and what to watch when sizing","introMarkdown":"Sizing a trunk balances the cost of idle channels against the cost of blocked calls, and a few specifics deserve attention before you settle on a number.\n\n### Add headroom, but not too much\n\nPlan capacity above your measured peak, since real traffic spikes past its average and calls sometimes hang up slower than expected.[4] A common margin is 20 to 30 percent over peak concurrency, enough to absorb a busy morning without paying year-round for channels that rarely fill.[4] Buy far beyond that and you are funding capacity that sits idle, while sizing exactly to the peak means a single unusual hour starts blocking calls.\n\n### Blocking is a business decision, not just a number\n\nThe blocking target you choose has a cost on both sides, because a one percent target buys more channels than a three percent target for the same traffic.[2] A sales line where a blocked call is a lost deal justifies the tighter target and the extra channels, while an internal helpdesk can often accept looser blocking and a smaller trunk.[2] The right figure follows from what a missed call actually costs you.\n\n### Metered plans change the math\n\nIf your provider bills per minute rather than per channel, the concurrency ceiling still matters for quality, but the monthly cost tracks usage instead of provisioned capacity.[8] Lines that sit quiet much of the day can be cheaper on a metered plan, while steady high volume usually favors a flat per-channel rate, so matching the billing model to your call pattern is part of sizing rather than a separate step.[8]\n\n### Bandwidth contention degrades calls before it blocks them\n\nA trunk sized correctly on paper can still sound bad if voice competes with other traffic on the same link, because congestion shows up as choppy audio well before it refuses a call.[6] Reserving bandwidth for voice with quality-of-service settings, and keeping headroom on the connection, is what protects the calls you sized for.[6]","introHtml":"Sizing a trunk balances the cost of idle channels against the cost of blocked calls, and a few specifics deserve attention before you settle on a number.
\nPlan capacity above your measured peak, since real traffic spikes past its average and calls sometimes hang up slower than expected.[4] A common margin is 20 to 30 percent over peak concurrency, enough to absorb a busy morning without paying year-round for channels that rarely fill.[4] Buy far beyond that and you are funding capacity that sits idle, while sizing exactly to the peak means a single unusual hour starts blocking calls.
\nThe blocking target you choose has a cost on both sides, because a one percent target buys more channels than a three percent target for the same traffic.[2] A sales line where a blocked call is a lost deal justifies the tighter target and the extra channels, while an internal helpdesk can often accept looser blocking and a smaller trunk.[2] The right figure follows from what a missed call actually costs you.
\nIf your provider bills per minute rather than per channel, the concurrency ceiling still matters for quality, but the monthly cost tracks usage instead of provisioned capacity.[8] Lines that sit quiet much of the day can be cheaper on a metered plan, while steady high volume usually favors a flat per-channel rate, so matching the billing model to your call pattern is part of sizing rather than a separate step.[8]
\nA trunk sized correctly on paper can still sound bad if voice competes with other traffic on the same link, because congestion shows up as choppy audio well before it refuses a call.[6] Reserving bandwidth for voice with quality-of-service settings, and keeping headroom on the connection, is what protects the calls you sized for.[6]
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":7},{"id":"a0ee5a00-c55d-4a24-959f-c96b876e3d3a","sectionKey":"what_it_is_not","sectionType":"markdown_section","heading":"What the concurrent-call number is not","introMarkdown":"The concurrent-call count is a specific measure, and it gets confused with several nearby figures that size differently.\n\n### It is not your number of employees or phones\n\nConcurrency counts calls happening at the same instant, not the people or handsets that could place them, and the gap between the two is usually large.[5][9] A team of fifty rarely exceeds fifteen or twenty simultaneous calls, so sizing to headcount overbuys the trunk.[9]\n\n### It is not your count of phone numbers\n\nDirect inward dial numbers and channels are billed and sized separately, because a number is an address while a channel is a call path.[5] You can hold hundreds of numbers on a trunk that carries a dozen concurrent calls, since most numbers are idle at any moment.[5]\n\n### It is not the number of SIP trunks you buy\n\nA single SIP trunk can carry many channels, so the number of trunks and the number of concurrent calls are different quantities.[8] Providers express capacity as sessions or channels within a trunk, and one trunk with enough channels serves most organizations without adding more trunks.[8]\n\n### It is not a permanent figure\n\nChannel capacity is adjustable in software, so the number is a setting you revisit as call volume changes rather than a fixed circuit you live with.[11][4] Reviewing busy-hour concurrency every few months keeps the trunk sized to current demand instead of last year's.[4]","introHtml":"The concurrent-call count is a specific measure, and it gets confused with several nearby figures that size differently.
\nConcurrency counts calls happening at the same instant, not the people or handsets that could place them, and the gap between the two is usually large.[5][9] A team of fifty rarely exceeds fifteen or twenty simultaneous calls, so sizing to headcount overbuys the trunk.[9]
\nDirect inward dial numbers and channels are billed and sized separately, because a number is an address while a channel is a call path.[5] You can hold hundreds of numbers on a trunk that carries a dozen concurrent calls, since most numbers are idle at any moment.[5]
\nA single SIP trunk can carry many channels, so the number of trunks and the number of concurrent calls are different quantities.[8] Providers express capacity as sessions or channels within a trunk, and one trunk with enough channels serves most organizations without adding more trunks.[8]
\nChannel capacity is adjustable in software, so the number is a setting you revisit as call volume changes rather than a fixed circuit you live with.[11][4] Reviewing busy-hour concurrency every few months keeps the trunk sized to current demand instead of last year's.[4]
\n","outroMarkdown":null,"outroHtml":null,"contentJson":{},"configJson":{},"noteMarkdown":null,"noteHtml":null,"sortOrder":8}],"citations":[{"title":"RFC 3261: SIP: Session Initiation Protocol","url":"https://datatracker.ietf.org/doc/html/rfc3261","excerpt":"an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.","quoteText":null,"sourceRole":"PRIMARY","verifiedAt":"2026-07-18T00:00:00","supportsText":"SIP is the signaling protocol that creates, modifies, and terminates sessions such as Internet telephone calls; one call session corresponds to one channel or call path on the trunk","domain":"datatracker.ietf.org","publisherName":"IETF"},{"title":"Sizing a trunk group using the Erlang B traffic model","url":"https://www.erlang.com/support/sizing-a-trunk-group/","excerpt":"A figure of 0.01 means that 1% of calls would be blocked; this is a normal figure to use in traffic engineering.","quoteText":null,"sourceRole":"INDEPENDENT","verifiedAt":"2026-07-18T00:00:00","supportsText":"Erlang B trunk-group sizing: busy-hour traffic equals calls per hour times average call duration in seconds divided by 3600; 0.01 (1 percent) blocking is the normal traffic-engineering target and 0.03 (3 percent) a relaxed one; worked example of 17.5 Erlangs at 1 percent blocking requires 27 lines","domain":"erlang.com","publisherName":"Westbay Engineers (erlang.com)"},{"title":"Resource Dimensioning Using Erlang-B and Erlang-C","url":"https://www.eventhelix.com/congestion-control/resource-dimensioning-using-erlang-b-and-erlang-c/","excerpt":"Erlang-B ... should be used when failure to get a free resource results in the customer being denied service.","quoteText":null,"sourceRole":"INDEPENDENT","verifiedAt":"2026-07-18T00:00:00","supportsText":"Erlang B applies when a blocked request is denied service, which fits trunk lines, while Erlang C applies when the request is queued, which fits call-center agents; busy-hour traffic measured in Erlangs; blocking probability defines grade of service","domain":"eventhelix.com","publisherName":"EventHelix"},{"title":"SIP Trunk Capacity Planning: How Many Channels Do You Need?","url":"https://www.ipcomms.net/blog/sip-trunk-capacity-planning/","excerpt":"plan for roughly 1 SIP channel per 3-4 employees ... 1 channel per 1-1.25 agents.","quoteText":null,"sourceRole":"INDEPENDENT","verifiedAt":"2026-07-18T00:00:00","supportsText":"Office rule of thumb about one channel per three to four employees (10 employees roughly 3 to 4 channels, 50 roughly 13 to 17, 100 roughly 25 to 30), call center roughly one channel per one to 1.25 agents; Erlang example of 6 Erlangs needing about 11 channels at 1 percent blocking; recommends about ","domain":"ipcomms.net","publisherName":"IPComms"},{"title":"Understanding SIP Trunk Capacity: Concurrent Call Limits","url":"https://www.sip.us/blog/insights/how-many-concurrent-calls-can-a-sip-trunk-handle/","excerpt":"A good rule of thumb is to plan for one SIP channel (or line) per concurrent call.","quoteText":null,"sourceRole":"INDEPENDENT","verifiedAt":"2026-07-18T00:00:00","supportsText":"No fixed number of calls a SIP trunk can handle; plan one channel per concurrent call and about one channel per three to four employees; each channel needs about 85 to 115 kbps depending on codec; a 10 Mbps link could support 80 to 100 calls","domain":"sip.us","publisherName":"SIP.US"},{"title":"How Many Calls Can a SIP Trunk Handle? A Comprehensive Guide","url":"https://flowroute.com/blog/how-many-calls-can-a-sip-trunk-handle-a-comprehensive-guide/","excerpt":"Maximum Call Capacity = Available Bandwidth (kbps) / Bandwidth per Call (kbps).","quoteText":null,"sourceRole":"INDEPENDENT","verifiedAt":"2026-07-18T00:00:00","supportsText":"Standard trunk typically handles 20 to 25 concurrent calls, high-capacity up to about 100, and some cloud trunks are unlimited; maximum call capacity equals available bandwidth divided by bandwidth per call; a 2 Mbps link at G.711 gives about 25 calls; G.711 about 64 kbps and G.729 about 8 kbps per ","domain":"flowroute.com","publisherName":"Flowroute"},{"title":"How Many Calls Can A SIP Trunk Handle?","url":"https://didlogic.com/blog/sip-trunk-capacity-for-calls/","excerpt":"SIP trunk capacity isn't defined by a fixed number of channels, it depends on factors like bandwidth, codec choice, network configuration, and provider-imposed soft limits.","quoteText":null,"sourceRole":"INDEPENDENT","verifiedAt":"2026-07-18T00:00:00","supportsText":"SIP trunk capacity is not a fixed channel count; it depends on bandwidth, codec choice, network configuration, and provider-imposed soft limits; concurrency benchmarks of retail call center 40 to 60 percent, law firm 10 to 20 percent, SaaS support 15 to 30 percent; estimated concurrent calls equals ","domain":"didlogic.com","publisherName":"DIDLogic"},{"title":"How Many SIP Trunks Do I Need? Formula + Online Calculator","url":"https://www.net2phone.com/blog/how-to-calculate-the-amount-of-sip-trunks-needed","excerpt":"Number of SIP trunks = Sessions per SIP Trunk / Peak Concurrent Calls.","quoteText":null,"sourceRole":"INDEPENDENT","verifiedAt":"2026-07-18T00:00:00","supportsText":"Number of SIP trunks equals sessions per SIP trunk divided by peak concurrent calls; rough estimate of about one session per two to three employees; recommends an Erlang B calculator for detailed sizing; a single trunk carries many channels","domain":"net2phone.com","publisherName":"net2phone"},{"title":"Tips for planning SIP trunk bandwidth","url":"https://www.business.att.com/learn/tech-advice/tips-for-planning-sip-trunk-bandwidth.html","excerpt":"SIP Trunk Peak Bandwidth = Peak CCP x 80Kb.","quoteText":null,"sourceRole":"INDEPENDENT","verifiedAt":"2026-07-18T00:00:00","supportsText":"Peak bandwidth equals peak concurrent call paths times per-call bandwidth (80 Kb for G.711, 32 Kb for G.729a); capacity is measured by bandwidth, not lines or connections; peak concurrent call paths can be derived from PRI call history or an Erlang calculator; 200 concurrent calls at G.711 needs 16 ","domain":"business.att.com","publisherName":"AT&T Business"},{"title":"ITU-T G.711: Pulse code modulation (PCM) of voice frequencies","url":"https://www.itu.int/rec/T-REC-G.711/","excerpt":"Pulse code modulation (PCM) of voice frequencies. Status: In force.","quoteText":null,"sourceRole":"PRIMARY","verifiedAt":"2026-07-18T00:00:00","supportsText":"G.711 specifies pulse code modulation of voice frequencies at 64 kbit/s, the uncompressed narrowband payload used to size per-call bandwidth; status in force","domain":"itu.int","publisherName":"International Telecommunication Union (ITU-T)"},{"title":"A Guide to SIP Trunking vs PRI: Pros and Cons, Benefits & TCO Breakdown","url":"https://www.atlantech.net/blog/sip-trunking-vs-pri","excerpt":"Sold by vendors on a per-channel basis on-demand, so you only pay for the capacity needed.","quoteText":null,"sourceRole":"SUPPORTING","verifiedAt":"2026-07-18T00:00:00","supportsText":"Corroborates that SIP channels are sold per channel on demand and can be added or removed as needed, while a PRI provides a fixed block of concurrent voice channels. Corroborated by [9] and [4]","domain":"atlantech.net","publisherName":"Atlantech Online"}],"revisions":[],"relatedAnswers":[{"id":"460c9c02-3a75-4382-b125-ea1587c82aa8","slug":"what-kind-of-internet-connection-and-bandwidth-do-i-need-for-sip-trunking","question":"What kind of internet connection and bandwidth do I need for SIP trunking?","publishedAt":"2026-07-18T15:16:59.312","confidenceScore":90,"confidenceLabel":"High","industry":{"id":"ff619d7c-d7d7-485e-a05a-53fba07f33ed","slug":"telecommunications","label":"Telecommunications","description":"Business voice, fiber, UCaaS, and network services"},"topic":{"slug":"sip-trunking","label":"SIP Trunking","description":"SIP trunking for business voice: how it works, channels, bandwidth, and PBX connectivity.","schemaKind":null},"contributor":{"id":"ec39deab-44fe-48d8-9029-fefe993ab85a","slug":"answer-stack","displayName":"AnswerStack","websiteUrl":null},"snippet":"SIP trunking runs over a standard broadband connection, but its size and quality both matter. Budget about 85 to 90 kbps per simultaneous call on G.711 or roughly 31 kbps on G.729a, multiply by your busy-hour concurrent calls, and add 10 to 20 percent of headroom. The connection also has to hold one-way latency under about 150 ms, jitter under about 30 ms, and packet loss under roughly 1 percent, with upload usually the limiting direction. A symmetric business or fiber link with quality of service is the common recommendation.","url":"/q/what-kind-of-internet-connection-and-bandwidth-do-i-need-for-sip-trunking"},{"id":"c1c7b4b5-5d54-4723-8305-65e598b2bcbb","slug":"what-equipment-do-i-need-to-use-sip-trunking","question":"What equipment do I need to use SIP trunking?","publishedAt":"2026-07-18T15:16:57.319","confidenceScore":90,"confidenceLabel":"High","industry":{"id":"ff619d7c-d7d7-485e-a05a-53fba07f33ed","slug":"telecommunications","label":"Telecommunications","description":"Business voice, fiber, UCaaS, and network services"},"topic":{"slug":"sip-trunking","label":"SIP Trunking","description":"SIP trunking for business voice: how it works, channels, bandwidth, and PBX connectivity.","schemaKind":null},"contributor":{"id":"ec39deab-44fe-48d8-9029-fefe993ab85a","slug":"answer-stack","displayName":"AnswerStack","websiteUrl":null},"snippet":"SIP trunking runs on ordinary business equipment rather than dedicated phone-company circuits: a SIP-capable phone system (an on-site IP-PBX or a hosted PBX), IP desk phones or softphones, a session border controller at the edge, and an internet link sized for your busy-hour calls. Analog phones or a legacy PRI system connect through an adapter or gateway. A hosted setup shifts most of this into the provider's data center and leaves little more than phones and a solid network in your building.","url":"/q/what-equipment-do-i-need-to-use-sip-trunking"},{"id":"5dd7bb8f-a2ec-4293-ad95-35aba460ad29","slug":"can-i-use-sip-trunking-with-my-existing-phone-system","question":"Can I use SIP trunking with my existing phone system?","publishedAt":"2026-07-18T15:16:55.298","confidenceScore":90,"confidenceLabel":"High","industry":{"id":"ff619d7c-d7d7-485e-a05a-53fba07f33ed","slug":"telecommunications","label":"Telecommunications","description":"Business voice, fiber, UCaaS, and network services"},"topic":{"slug":"sip-trunking","label":"SIP Trunking","description":"SIP trunking for business voice: how it works, channels, bandwidth, and PBX connectivity.","schemaKind":null},"contributor":{"id":"ec39deab-44fe-48d8-9029-fefe993ab85a","slug":"answer-stack","displayName":"AnswerStack","websiteUrl":null},"snippet":"Whether a SIP trunk fits your current phone system comes down to what that system is. Most IP-PBX platforms from the past decade speak SIP and connect by pasting in provider credentials. A legacy PBX on PRI or T1 connects through a digital gateway that converts SIP to the circuit it expects, and analog phones connect through an FXS adapter. Keeping the system you have avoids a full replacement, but the trunk still depends on your internet link and carries 911 obligations.","url":"/q/can-i-use-sip-trunking-with-my-existing-phone-system"},{"id":"15b4d605-db80-4b61-876a-d42f6308be0d","slug":"what-is-a-sip-trunk-channel","question":"What is a SIP trunk channel?","publishedAt":"2026-07-18T15:01:36.739","confidenceScore":90,"confidenceLabel":"High","industry":{"id":"ff619d7c-d7d7-485e-a05a-53fba07f33ed","slug":"telecommunications","label":"Telecommunications","description":"Business voice, fiber, UCaaS, and network services"},"topic":{"slug":"sip-trunking","label":"SIP Trunking","description":"SIP trunking for business voice: how it works, channels, bandwidth, and PBX connectivity.","schemaKind":null},"contributor":{"id":"ec39deab-44fe-48d8-9029-fefe993ab85a","slug":"answer-stack","displayName":"AnswerStack","websiteUrl":null},"snippet":"A SIP trunk channel is one simultaneous call path: each active call, inbound or outbound, uses one channel and releases it when the call ends. Channel count, not how many phone numbers you own, sets how many calls run at once. Capacity is virtual and limited mainly by bandwidth, roughly 85 to 115 kbps per channel, so channels scale in software rather than through new circuits. Providers sell either fixed channel bundles or elastic trunks that cap calls per second instead.","url":"/q/what-is-a-sip-trunk-channel"}],"contributorStats":{"verifiedAnswers":224,"openDisputes":0},"schemaJson":{"@context":"https://schema.org","@type":"Question","name":"How many simultaneous calls do I need or get on a SIP trunk?","text":"How many simultaneous calls do I need or get on a SIP trunk?","url":"https://www.answerstack.io/q/how-many-simultaneous-calls-do-i-need-or-get-on-a-sip-trunk","answerCount":1,"datePublished":"2026-07-18T15:16:53.422","author":{"@type":"Person","name":"AnswerStack Editorial Team","worksFor":{"@type":"Organization","name":"AnswerStack"},"url":"https://www.answerstack.io/contributors/answer-stack"},"about":[{"@type":"Thing","name":"SIP Trunking"},{"@type":"Thing","name":"Telecommunications"}],"acceptedAnswer":{"@type":"Answer","text":"The number you need is the count of calls your busiest hour runs at the same time, not the number of employees, phones, or numbers you hold, and each of those calls occupies one channel, or SIP session, on the trunk.[1][5] A common starting point for a general office is one channel for every three to four employees, while a contact center needs closer to one channel per active agent, but the accurate way to size it is to feed your busy-hour call volume and average call length into an Erlang B calculation at a one percent blocking target.[4][5][2][3] The number you actually get is not fixed by the trunk itself: capacity is limited by your internet bandwidth, your codec, and any per-plan cap your provider sets, since each concurrent call consumes roughly 80 to 115 kilobits per second once packet overhead is counted.[6][7][5] As a rough ceiling, a clean 2 megabit connection carries about 25 G.711 calls, and providers can raise or lower your channel count in software rather than installing new circuits.[6][4][11]","url":"https://www.answerstack.io/q/how-many-simultaneous-calls-do-i-need-or-get-on-a-sip-trunk","upvoteCount":0,"datePublished":"2026-07-18T15:16:53.422","dateModified":"2026-07-18T00:00:00","author":{"@type":"Person","name":"AnswerStack Editorial Team","worksFor":{"@type":"Organization","name":"AnswerStack"},"url":"https://www.answerstack.io/contributors/answer-stack"},"citation":[{"@type":"CreativeWork","name":"RFC 3261: SIP: Session Initiation Protocol","url":"https://datatracker.ietf.org/doc/html/rfc3261"},{"@type":"CreativeWork","name":"Sizing a trunk group using the Erlang B traffic model","url":"https://www.erlang.com/support/sizing-a-trunk-group/"},{"@type":"CreativeWork","name":"Resource Dimensioning Using Erlang-B and Erlang-C","url":"https://www.eventhelix.com/congestion-control/resource-dimensioning-using-erlang-b-and-erlang-c/"},{"@type":"CreativeWork","name":"SIP Trunk Capacity Planning: How Many Channels Do You Need?","url":"https://www.ipcomms.net/blog/sip-trunk-capacity-planning/"},{"@type":"CreativeWork","name":"Understanding SIP Trunk Capacity: Concurrent Call Limits","url":"https://www.sip.us/blog/insights/how-many-concurrent-calls-can-a-sip-trunk-handle/"},{"@type":"CreativeWork","name":"How Many Calls Can a SIP Trunk Handle? A Comprehensive Guide","url":"https://flowroute.com/blog/how-many-calls-can-a-sip-trunk-handle-a-comprehensive-guide/"},{"@type":"CreativeWork","name":"How Many Calls Can A SIP Trunk Handle?","url":"https://didlogic.com/blog/sip-trunk-capacity-for-calls/"},{"@type":"CreativeWork","name":"How Many SIP Trunks Do I Need? Formula + Online Calculator","url":"https://www.net2phone.com/blog/how-to-calculate-the-amount-of-sip-trunks-needed"},{"@type":"CreativeWork","name":"Tips for planning SIP trunk bandwidth","url":"https://www.business.att.com/learn/tech-advice/tips-for-planning-sip-trunk-bandwidth.html"},{"@type":"CreativeWork","name":"ITU-T G.711: Pulse code modulation (PCM) of voice frequencies","url":"https://www.itu.int/rec/T-REC-G.711/"},{"@type":"CreativeWork","name":"A Guide to SIP Trunking vs PRI: Pros and Cons, Benefits & TCO Breakdown","url":"https://www.atlantech.net/blog/sip-trunking-vs-pri"}]}}}