When the Trunk Isn't Broken, It's Cancelled

Analysis Date: September 7, 2026 System: 3CX V20 Update 9 (Build 995), PRO Edition, 8 concurrent calls, self-hosted Customer: A consulting firm with clients in Switzerland Support: Bitblade Solutions UG

Anonymized case example from daily operations — company name, phone numbers, and IP addresses have been removed.

The Symptom

Customer Report: "The system is dead, or rather, it only partially works."

That phrasing is the interesting part. "Dead" would be simple — then the service isn't running, and you restart it. "Partially" means: something works, something doesn't, and nobody knows where the line is.

A glance at the web client confirmed it: The interface loaded, all 35 extensions were displayed — but practically every one showed the status "Not Registered".

The Diagnostic Path

Step 1: System Overview, Not Guesswork

The admin console (#/office/dashboard) delivers more in 30 seconds than an hour of guessing:

Directly below that, the event log — and the answer was already there:

Warning 12294  09/07/2026 12:03  SIP Server
Call or Registration to iway has failed.
sip:10001@sip3.phone.iway.ch replied: 401 Unauthorized;

The same line, every five minutes, across 240 pages of logs. The oldest retained entries were from about a month before — that's not the start of the fault, but the end of log retention.

Step 2: Trunk Status

Under Trunks & Chat, the expected picture:

This explained "only partially works": The German trunk accepted calls, the Swiss one was dead.

Step 3: The False Lead

A 401 Unauthorized looks like a wrong password. The reflex: re-enter SIP credentials, done.

That reflex would have cost an hour and solved nothing.

Step 4: Check with the Provider

Instead of guessing in 3CX, a look at the iWay customer portal:

• Active Products: 0
• Outstanding Invoices: 0 — Amount Due: 0.00 CHF
• Under inactive products: a VoIP Business Trunk Flat rate, quarterly, approximately 150 CHF

And the invoice history showed three regular billings from the past — and on a later date, three entries marked "Doubtful Debt Write-off" for exactly the same three billing periods.

The Cause

The trunk was not disrupted. It was cancelled.

"Doubtful Debt Write-off" is the accounting term for bad debt write-off. The provider wrote off the outstanding amounts from three billing periods and deactivated the product. The registered SIP account no longer exists — hence the 401 Unauthorized, and hence no re-entered password would ever have worked.

The fact that "Outstanding Invoices: 0" appeared in the portal was the most insidious indicator in the entire case: It looked like "everything paid, everything in order." Actually it meant "written off, contract terminated."

The customer's Swiss phone number has thus been dead for about eighteen months.

The Real Damage

The dead trunk was only half the story. A look at the outbound rules revealed the more costly part:

Before:

Three rules sent every call to Switzerland to the dead trunk — with no fallback route whatsoever. Routes 2 through 5 were consistently set to "Blocked."

3CX processes rules from top to bottom. The +41 rule takes precedence over the general + rule. Result: Every dialing attempt to +41… or 0041… went to the dead trunk, found no fallback, and failed.

The customer couldn't call a single Swiss client for months. The routing hadn't cushioned the provider failure; it had compounded it: First the incoming CH number went away, then all outgoing CH connectivity disappeared — and nobody noticed one problem, because in daily use "the phone still rang".

Secondary Finding: The Unattended Queue

Concurrently in the log:

Info 105  09/07/2026 11:30  Queue Manager
Lost Call in Queue (800)

Four lost calls in just the morning of the analysis date. The reason was independent of the trunk:

• Under Phones, one single device was registered: the 3CX App for Windows on a single extension
• Another extension had a desk phone configured — status red, not registered
• 33 additional users: no device, no app

Checked whether anything was blocking it:

• IP blacklist: empty
• Spot check on one extension: "Extension disabled" not set, "External calls disabled" not set

No technical block. The system accepted calls, placed them in queue 800 — and nobody was there.

The Second Safety Net That Was Also Missing

The obvious question: A queue does have an overflow destination. Where do calls go when nobody answers?

The queue configuration:

Two things stand out.

First: the queue's only agent is the Admin account — no human at the phone. It was never logged in. The queue thus had structurally zero agents.

Second: the overflow worked — it just pointed to a dead endpoint. That exact external number shows up throughout the event log all day:

08:22 → 408 Request Timeout
08:26 → 408 Request Timeout
08:32 → 486 Busy Here
08:33 → 408 Request Timeout
10:29 → 408 Request Timeout
10:31 → 408 Request Timeout
13:59 → 408 Request Timeout
15:11 → 486 Busy Here

This closes the loop: Call comes in over the German trunk → lands in the queue → 15 seconds of ringing at an account that's never logged in → forwarding to an external number that doesn't answer → caller hears nothing and hangs up → Lost Call in Queue.

The system thus had not one failed backup mechanism, but two in a row. And because both failed silently, everything looked normal from the outside: it was ringing.

And Why the Forwarding Failed

Obvious suspicion: the endpoint is dead like the iWay trunk. The SIP codes said otherwise.

486 Busy Here means the far end was reached and was busy. An unassigned endpoint returns 404 Not Found, not a busy signal. So twice a day the call went through to the destination. 408 Request Timeout means Reventix accepted the INVITE, forwarded it, and then waited in vain for a final response.

The reverse test confirmed it: A call from a mobile phone to the external number went through fine. The endpoint is alive, the forwarding destination is intentional and correct.

This left one suspect — the dial format. The number was entered in national format with a prepended 0049, so a number dialed internationally to Germany, sent from a German trunk. Via the "Standard 0" rule, that went to Reventix exactly as-is, with no digit manipulation. Some providers swallow that without complaint, others route it via an international path — and that's where such timeouts come from.

Corrected to E.164 format in all four queue destinations (no answer, outside hours, breaks, holiday) and in both destinations of the associated hunt group, which had the same number in the same wrong format.

What's notable: the error wasn't at the provider or the far end, but in a field that's been that way for years and probably worked fine in 95% of cases.

The Solution

Reventix replaces iway completely. 3CX has no disable switch for trunks (the context menu knows only edit and delete), so the switchover runs through the routing.

After:

Rule 5 was additionally renamed from "Outbound rule for iway" — a rule name pointing to a nonexistent provider is a time bomb for the next technician.

Additionally, in all five rules, Route 1 had the outgoing caller ID set to the publicly advertised main number of the company. Without this entry, every outbound call would have shown the trunk main number — a number no customer knows.

Important: This main number is not in the Reventix trunk's number block and is also not entered as a DID in 3CX. That's not an error — the DID list in 3CX controls only inbound routing and is not a whitelist for outbound numbers. Whether a foreign CLI gets through depends solely on the provider: It must be released at the trunk provider as a permitted sender number (CLIP no screening). If not, the provider either rejects the call or silently overwrites the number. According to the customer, the approval was in place here.

No digit manipulation was needed: Both affected rules were set to "No digits removed" with no prepending. +41… goes to Reventix as E.164, 0041… as an internationally dialed number — the German trunk accepts both.

After saving and reloading, verified: no rule points to iway anymore.

Open Items

Immediate:

• The iway trunk still exists and attempts to register unsuccessfully every 5 minutes. It routes nothing anymore, but continues to generate log noise. Deleting it ends that — the configuration is documented and recoverable.
• Outbound calls to Switzerland now display a German phone number as the caller ID. For a company with Swiss clients, that's a business decision, not a technical one.
• Test call pending: The new outgoing number has been set in all five rules but not yet tested in production. A call to a mobile phone will show in seconds whether Reventix passes the CLI, overwrites it, or rejects the call. Two of the five rules (+41 and 0041) were visually rechecked after saving; the other three (+, Standard 0, CH Outbound) should be opened again at some point, as the admin console hung several times during the work.

To clarify with the provider:

• Is the old Swiss number still assigned or already released? After eighteen months, the latter is likely.
• Reactivation or new order possible? After a bad debt write-off, expect prepayment or credit check.
• If the number is lost: new CH number from a Swiss VoIP provider. Porting is practically impossible with a written-off contract.

Independently:

• 34 of 35 users have no endpoint. That currently costs more calls than the dead CH number ever did.
• The queue has only the Admin account as an agent. Real consultants must be registered as agents and logged in, otherwise nothing changes.
• The overflow destination was corrected to E.164. Whether that eliminates the 408s will only show in production — a test call to the queue that nobody answers is the quickest check.
• 15 seconds maximum wait time in the queue is very short. Even with logged-in agents, there's barely time to pick up the phone.
• Remote storage is not configured — backups are on the same machine.
• The license expires soon.
• The Reventix trunk occasionally flaps (brief de-registration and re-registration, occasional timeouts on outbound calls). Monitor.

Key Takeaways

A 401 is not always a password problem. SIP has no status code for "Your contract was cancelled." The provider responds with the same 401 Unauthorized as for a typo. The error message describes the symptom, not the cause — and whoever looks only in the phone system will never find the cause.

Check the contract level before touching the technology. The decisive finding wasn't in 3CX, but in an invoice history. Five minutes in the provider's customer portal save hours of SIP tracing.

"Outstanding Invoices: 0" doesn't mean "everything paid." It can also mean "written off." A portal that shows clean numbers can still describe a terminated contract.

Routing without fallback is a single point of failure by design. Routes 2 through 5 were set to "Blocked." If just the existing Reventix trunk had been entered as a fallback, the provider outage would never have affected outbound connectivity — the outage would have remained invisible instead of going unnoticed for months.

A silent failure is more expensive than a loud one. If the system had stopped working entirely, it would have been fixed the same day. Because "the phone still worked", a half-failure scenario ran for months — including lost calls in an unattended queue.

Name rules by function, not by current provider. "Outbound rule for iway" was a lie in the configuration tree since the cancellation.

Event logs have an expiration date. 240 pages sounds like a lot; here it went back only 30 days. Whoever wants to reconstruct the start of a fault needs external monitoring — not the log of the system that was affected itself.

---

All information from an actual customer project. Company name, phone numbers, IP addresses, and billing amounts anonymized. Current as of: September 2026.