Cause-based routing and failover
A cause rule answers one question: on this provider, when a call comes back with a specific dial result, what should happen next — try another provider, try the same one again with a new caller ID, forward it somewhere, or just let it fail?
This sits below LCR routing: the LCR decides the order of providers to try, while a cause rule decides what a specific failure from a specific provider actually triggers — the plain "try the next one" failover, or something more specific.
Provider rules and global rules
Cause rules exist at two levels, reached from two different places:
- Provider rules — open a provider (Routing > Providers) and select Cause-Rules along the top. Apply only to that provider.
- Global rules — Routing > Cause rules in the sidebar. Apply to every provider that has no matching rule of its own.
Provider-specific rules always take precedence over global ones.
Building a rule
Click Create rule (or Edit on an existing one). The If (match) side narrows which attempts the rule fires on; the Then (action) side decides what happens.
| Field | Meaning |
|---|---|
Priority (low = first) | Rules are checked in this order; the first one that matches wins. |
DIALSTATUS | The dial result to match: All, BUSY, NOANSWER, CHANUNAVAIL (unreachable) or CONGESTION (overloaded / rejected). ANSWER and CANCEL are never evaluated by rules — a rule cannot fire on a call that was actually answered. |
Q.850 codes (empty = all) | A comma list, with ranges (e.g. 21,34,38-44) — narrows the match to specific hangup causes on top of DIALSTATUS. The dropdown above it adds a code by name from the same list documented in Statistics: profit, hangup causes & loss-making calls. |
Target prefix (empty = all) | Restricts the rule to destination numbers starting with this prefix, e.g. a country code. |
Action | What happens once the rule matches — see below. |
The six actions
| Action | What it does |
|---|---|
Next provider - same caller ID | Plain failover: try the next provider in the LCR's order, keeping the same outbound caller ID. |
Next provider - new caller ID | Failover to the next provider, but pick a fresh caller ID for it. |
Same provider - new caller ID | Retry the same provider with a different caller ID, up to Max. retries (same provider) (1 or 2) — for cases where the provider itself is fine but rejected that particular number. |
Forward to extension | Send the call to a local device/extension instead of another provider. |
Fail finally (no further attempt) | Stop trying and fail the call — optionally with a specific Hangup code (CDR) recorded instead of the default. |
Treat as done (no failover) | Accept this result as final without treating it as a failure that needs another attempt. |
For either new-caller-ID action, the replacement number comes from the caller ID pool of the calling device, matched to the provider actually being tried next — set on the device under CID pools and on the pool under Valid for provider (see Number pools). It never borrows another device's number.
The dry-run simulator
Every Cause-Rules page (provider or global) has a Simulation (dry run) panel: enter a Target number, a DIALSTATUS and a Q.850 code, click Simulate, and it shows which rule would fire — using the exact same matcher as live calls, without placing one.
Global rules
The global page works the same way, but applies to every provider that has no rule of its own for that dial result — useful for a default like "on congestion, retry once with a new caller ID" without repeating it on every provider.
Changes take effect in live routing after at most 60 seconds (the engine caches rules) — a rule you just saved will not necessarily apply to a call placed in the same second. Use the simulator to check it immediately instead of placing a real test call.
Check
Open a provider's Cause-Rules tab, run the simulator with the DIALSTATUS you expect to see in practice, and confirm the matched rule and its action are the ones you intended — then check Routing > Cause rules the same way for anything meant to apply globally.