SIP Channels & CPS Sizing for Dialers

Channels, CPS and why both matter

A channel is one simultaneous call, from the moment the INVITE is sent until the BYE. Ringing calls count. A CPS limit caps how many new INVITEs you may send in any one-second window. Channels limit how many calls can exist at once; CPS limits how fast you can start them.

Conversational traffic is almost always channel-bound: calls are long, so you hit the concurrency ceiling well before CPS matters. Dialer traffic is the opposite. Many attempts end within seconds, so concurrency stays modest while the start rate is high. Most dialer capacity problems are CPS problems.

Estimating concurrent channels

For a predictive or ratio dialer, a simple and reliable estimate is:

channels ≈ agents × (1 + dial_ratio) × 1.2

  agents        logged-in agents at peak
  dial_ratio    lines dialled per available agent
  1 + ...       agent's live call plus calls ringing for them
  × 1.2         20% headroom for transfers, recordings, bursts

Example: 60 agents at a dial ratio of 2.5 gives 60 × 3.5 × 1.2 = 252 channels. If you also run an IVR overflow or record calls on a separate leg, add those explicitly.

For an IVR campaign, use Little's Law: concurrent calls equal the arrival rate times average holding time. If you start 15 calls per second and each lasts 25 seconds on average including ringing, you need about 15 × 25 = 375 channels.

Estimating CPS

Average CPS is easy to calculate and almost useless on its own. What matters is the burst rate when many agents become available together, typically at shift start, after a break, or when a campaign is switched.

avg_cps   = attempts_per_hour / 3600
burst_cps ≈ (agents × dial_ratio) / burst_window_seconds

Example: 60 agents, ratio 2.5, all freed within 8 s
  burst_cps ≈ (60 × 2.5) / 8 ≈ 19 CPS

Ask your carrier for a limit at or above the realistic burst, and configure your dialer to pace below it. On VICIdial this is the campaign or server-level calls-per-second setting; in Asterisk you can pace originations with a queue or a simple rate limiter in your AGI.

Bandwidth per call

Bandwidth per call depends on codec, packetisation interval (ptime) and network overhead. Figures below are per direction, per call, at 20 ms ptime, including IP/UDP/RTP and Ethernet overhead.

Add 20–30% headroom for signalling, recordings uploaded over the same link and jitter. Our SIP channel & bandwidth calculator does these sums for any codec and channel count.

G.729 saves bandwidth but costs CPU on the transcoding side and degrades DTMF and AMD accuracy. Unless bandwidth is genuinely constrained, G.711 is the safer choice for dialers and IVR.

Server-side limits that bite first

• File descriptors. Asterisk opens several per call. Raise ulimit -n to 65,536 or more on dialer servers.
• RTP port range. Each call uses two UDP ports. The default 10000–20000 range supports about 5,000 calls; ensure your firewall allows the whole range.
• Recording I/O. Writing hundreds of simultaneous recordings to slow disks causes audio gaps. Use local SSD and move files asynchronously.
• SIP over UDP fragmentation. Large INVITEs with many codecs or headers can exceed the MTU. Trim codec lists or use TCP/TLS to the carrier.

[general]
rtpstart=10000
rtpend=20000
strictrtp=yes
icesupport=no

When to use Erlang B instead

The rule-of-thumb formulas above work for dialers because the dialer controls when calls start. Inbound traffic is different: callers arrive randomly, and you need enough channels that only a small share find the trunk full. That is what the Erlang B formula answers. One Erlang is one channel busy for one hour. If your busiest hour receives 900 calls averaging 3 minutes, offered traffic is 900 × 3 ÷ 60 = 45 Erlangs.

Note how the overhead shrinks as traffic grows: large trunk groups are more efficient than small ones. This is one reason to pool inbound DID numbers onto a shared trunk rather than giving each site its own small one.

Worked example: a 120-seat blended centre

A centre runs 90 outbound agents at a dial ratio of 2.2 and 30 inbound agents handling 42 Erlangs in the busy hour. Recordings are stored locally. The centre uses G.711.

• Outbound channels: 90 × 3.2 × 1.2 ≈ 346.
• Outbound burst CPS: (90 × 2.2) ÷ 8 s ≈ 25 CPS.
• Inbound channels: about 55 for 1% blocking at 42 Erlangs.
• Total channels: about 400. Bandwidth: 400 × 87 kbps ≈ 35 Mbps each way, so provision 45–50 Mbps symmetric.

The centre asks for 400 channels and 30 CPS outbound, splits outbound and inbound onto separate endpoints so a dialer burst cannot starve inbound calls, and reviews peaks monthly.

Network quality targets

Capacity is pointless if the link is poor. For good voice quality aim for one-way latency under 150 ms, jitter under 30 ms and packet loss under 1%. Mark RTP with DSCP EF (46) and SIP with CS3 (24), and make sure your edge router honours the marking. On shared internet links, a dedicated voice VLAN and traffic shaping on uploads prevents recordings and file transfers from interfering with calls.

Planning for seasonal peaks

Many campaigns are seasonal: open enrolment, tax deadlines, Q4 retail, back-to-school. Look at last year's peak hour, not the average month, and add the growth you expect in agent numbers. Request limit increases two to three weeks ahead so the carrier can provision capacity on the right partners rather than overflowing onto whatever is available on the day. After the peak, keep the higher limits for a week before reducing them, because campaigns rarely end on schedule.

Remember that CPS and channels interact with billing. If you are on a CC route with 6/6 billing, a larger burst capacity costs nothing extra in itself; you pay for minutes used. What it buys you is fewer rejected attempts, smoother agent occupancy and fewer retries.

Agreeing limits with your carrier

1. 1

   Share your peak numbers

   Tell the carrier your peak channels, burst CPS, traffic type and destinations. Capacity can then be provisioned on the right routes.

2. 2

   Confirm per-trunk and per-destination limits

   Some carriers apply CPS per destination as well as per account. Ask for both.

3. 3

   Test the burst

   During acceptance testing, deliberately ramp to your expected burst and watch for rejections. See the 7-day route acceptance test plan.

4. 4

   Monitor and revisit

   Review peak channels and CPS monthly. Campaigns grow, and limits that were right in spring may not be right in Q4.

In the CLIRoutes portal, channel and CPS limits are shown per endpoint and can be raised on request. SIP trunking customers can split capacity across several endpoints, for example one per site or per dialer cluster.