Which dialer customer burned your CPS route

You carry call-centre and dialer traffic for several customers on the same US or UK termination. One campaign opens at 09:00. Setup attempts spike. The upstream trunk answers with SIP 503 and congestion. A few minutes later every customer on that trunk is failing, including the quiet ones who never burst.

The dialer buyer sees a campaign that will not start. You see a shared route that one originator just burned for everyone.

This post is for the wholesale or VoIP operator who terminates dialer traffic: how to find which customer caused the spike, how to stop the next burst before it leaves your switch, how to put dialer customers on their own routes, and how to dry-run routing without ringing a carrier. For what CPS and concurrent channels mean, and why a dialer can see 503s while channels are still free, use the two neighbour posts linked below. This one starts after that.

Shared trunk, shared blast radius

Dialer traffic is bursty. A predictive campaign can fire many INVITEs in the first second after start or resume. Upstream carriers protect shared SIP capacity with CPS caps. Telnyx documents a default of 20 CPS per source IP on its standard trunking path, and rejects excess INVITEs with 503 CPS Limit reached. Vonage notes that traffic far above the CPS limit can be temporarily blocked to protect the platform and other customers.

If your customers share one termination trunk (or one source IP your upstream sees), their bursts share one CPS budget. Customer A’s campaign can spend that budget. Customers B and C then inherit the 503s, the temporary block, or the “your route is blocked” ticket from the carrier.

PortaOne’s traffic-density docs describe the same operator problem: auto-dialer bursts that overload components unless you cap call attempts per second per endpoint. Buying more concurrent channels does not fix that. Rate control and isolation on your side do, before the burst hits the shared carrier.

Find who burned it

When the floor fails for everyone, start with time and hangup, not with a vendor blame thread.

1. Pin the second. Note when the shared trunk started returning 503 or congestion. Campaign starts and resume events are the usual clocks.
2. Sort CDRs by origination point (or device) in that window. Look for the OP that jumped in INVITE rate while others stayed flat.
3. Read your own hangup codes first. On M4, hangup 304 means the originator’s CPS limit was reached. Related codes: 329 (terminator CPS), 342 (global incoming system CPS), 345 (terminator CPS inside a dial peer). Disconnect 826 is OP CPS; 802 is global CPS. On MOR, 244 is the device CPS abort and 243 is the provider skipped for CPS.
4. Separate your cap from the carrier’s. A 304 / 244 with no carrier 503 means your switch stopped that OP. A carrier 503 with none of those codes, and free channels on your side, means the burst reached the upstream CPS ceiling. Detail on that split: why dialers get 503s with free channels.
5. Name the customer before you reopen the trunk. Cap that OP, move its traffic, or both, before you ask the carrier to lift a block.

A teaching sketch (not a live trace): three customers share a trunk capped at 20 CPS upstream. At 09:00:01, Customer A’s dialer sends 45 INVITEs; B and C send 2 each. The carrier accepts 20 and rejects the rest. From 09:00:02, A, B, and C all see 503s on that trunk. Only A’s CDR pile shows the burst. B and C look like victims of a “dead route.”

Cap the customer before the carrier does

Set a CPS limit on the dialer originator at or under what that customer may send into your network. On M4, use Limit up to X calls, during Y seconds on the origination point (and on termination points or dial-peer / TP pairs when the limit belongs on the route). On MOR, the same control lives on the device and on the provider.

When your limit trips first, the hangup names the OP. Excess attempts never leave toward the carrier that would block everyone. M4 documents up to about 1,000 CPS system-wide (architecture-dependent). MOR documents about 100 CPS system-wide, with one Asterisk server closer to 20 in practice. Those are platform ceilings, not a reason to leave a single dialer OP uncapped on a shared trunk.

If CPS vs concurrent calls is still fuzzy, read calls per second vs concurrent calls, then return to the caps.

Put dialer customers on their own routes

Caps stop a burst from spending the shared CPS budget. Separate routes stop a burned or dialer-labelled trunk from taking retail and quiet wholesale traffic with it.

On M4, a dial peer is a routing group of termination points with destination and source rules. Dial peers sit in routing groups assigned to origination points. You can:

• Put dialer OPs on a routing group that only reaches dialer-tolerant (or dialer-contracted) termination points.
• Keep non-dialer customers on trunks and dial peers that never see that attempt pattern.
• Set CPS and call limits per dial-peer / termination-point pair so one terminator on a dialer peer cannot be hammered past its contract.
• Duplicate a dial peer when you need a dialer copy of a destination set, then change TP assignments and limits without rewriting the quiet peer.

If one dialer customer still burns its dedicated trunk, the ticket stays between you, that customer, and that carrier. The rest of the floor keeps working.

MOR operators with dialer devices on shared providers get the same idea with device and provider CPS limits, and with separate providers or LCRs for dialer traffic when volume justifies it. High dialer CPS above one Asterisk server is an M4 / Class 4 conversation, not a channel-pack increase on MOR.

Trace the path without ringing anyone

After you change OP caps or dial-peer assignments, confirm routing before the next campaign window.

M4 Call Tracing runs a fake call in real time. It walks the routing steps for an origination point with a chosen source and destination, or from a call in the calls list. M4 does not ring any terminator during Call Tracing. Red errors in the call log show where the attempt would stop (missing dial peer, inactive OP, CPS or capacity limit, and so on).

Use it when you need to know whether Customer A still lands on the shared UK trunk, or whether the new dialer dial peer takes that traffic. For what already happened on a past call, use the call log / call info for that CDR instead of re-tracing.

Prevention checklist

• Mark which OPs are dialer or predictive before they go live.
• Cap each dialer OP at or under its allowed CPS into your network.
• Keep dialer traffic on dial peers / trunks contracted for that pattern.
• Alert on a jump in 304 / 244 (or carrier 503) concentration on one OP.
• Re-run Call Tracing after any routing group or dial-peer change that affects dialer OPs.
• Put the dialer customer’s CPS number next to concurrent channels in the quote. Channels alone are incomplete for this traffic.

FAQ

Why do quiet customers fail when only one dialer bursts?

They share the upstream CPS budget (often one trunk or one source IP the carrier meters). When that budget is spent or the trunk is blocked, every OP on it fails.

Which hangup means my switch stopped the dialer OP?

On M4, 304 (originator CPS). On MOR, 244 (device CPS). Carrier 503 without those codes means the reject came from upstream.

Does Call Tracing place a real call?

No. M4 Call Tracing makes a fake attempt and does not ring terminators. Use call info for a past real CDR.

Is a bigger concurrent-call pack enough for dialer customers?

No. Concurrent calls and CPS are different counters. Size and isolate for attempt rate, then for channels. See the CPS vs concurrent calls post linked above.

Next step

If you terminate dialer traffic on a Class 4 switch, walk one dialer OP through OP CPS limits, dial-peer separation, and Call Tracing on the M4 SBC online demo (web UI only; no real calls). Compare MOR and M4 fit on the MOR vs M4 SBC page when the question is platform capacity, not one bad campaign hour.