A phone number used to be a copper pair. Today it is a software-defined route that touches originating carriers, SIP trunks, DNS records, session border controllers, codecs, NAT devices, and STIR/SHAKEN attestation engines before it ever reaches your PBX. Each of those hops is a point of failure — and most of them fail silently, without tripping a PBX alarm. This is why a VoIP DID can be officially “up” and still send every caller to dead air, one-way audio, or a “Spam Likely” label that nobody answers.
This article walks through the nine most common failure points in the VoIP DID chain, the metrics that expose each one, and — most importantly — how Phone Number Monitoring’s synthetic-call infrastructure catches each failure mode before it reaches a customer.
What Is a DID in a VoIP World?
A Direct Inward Dialing (DID) number is a telephone number routed directly to a specific endpoint — an extension, queue, IVR menu, or mobile device — without passing through a main switchboard. In traditional TDM telephony, a DID rode over a dedicated PRI or T1 circuit. In a modern VoIP deployment, that same DID is delivered over an IP-based SIP trunk from a carrier (ITSP) and translated into a SIP URI such as sip:+14155550123@trunk.example.com.
The trade-off is clear: VoIP DIDs are cheaper, portable, and infinitely scalable — but they inherit every failure mode of the internet, the SIP protocol, and the downstream signaling stack. That is why VoIP DID monitoring has become a distinct discipline from traditional line-availability checks.
The VoIP DID Failure Chain: 9 Points Where a Phone Number Quietly Breaks
Below is the anatomy of a modern inbound call, in the order it actually executes. Each stage is a discrete failure domain that requires its own probe.
1. Originating Carrier & Number Portability
When a caller dials your DID, the originating carrier queries the North American LERG (Local Exchange Routing Guide) and LIDB to determine the current owner. For ported numbers, it performs an LRN (Location Routing Number) dip to find the actual terminating carrier. Failure modes include stale LRN data after a port, RespOrg mistakes on toll-free numbers, and routing loops during the FOC (Firm Order Commitment) window. Symptoms: fast-busy, intercept messages, or calls delivered to the previous carrier for days after a port.
2. SIP Trunk Registration & Authentication
Your PBX or SBC maintains a persistent SIP registration with the ITSP. A lapsed registration, an expired TLS certificate on port 5061, or a credential change can cause the trunk to go into a rejecting state — returning SIP/2.0 403 Forbidden or 401 Unauthorized — while your internal extensions continue to work perfectly. Without external probing, you will not see this until inbound calls stop.
3. DNS, SRV Records, and ENUM Resolution
SIP endpoints are discovered through DNS SRV records (_sip._udp.example.com). A misconfigured TTL, a DNSSEC validation error, or a lapsed domain can break call routing even though every device on the network is healthy. ENUM-based least-cost routing adds another lookup layer that can silently fail.
4. Session Border Controller & Codec Negotiation
The SBC brokers the SDP handshake between the carrier and your PBX. If the offered codec list (G.711, G.722, Opus, G.729) does not intersect, the call either fails with 488 Not Acceptable Here or — worse — completes but transcodes so poorly that MOS drops below 3.0. Asymmetric codec support is a common cause of “calls connect but sound terrible” complaints that PBX logs never flag.
5. NAT Traversal & SIP ALG Interference
This is the single most common cause of one-way audio in SMB deployments. A SIP Application Layer Gateway on a consumer-grade firewall rewrites SIP headers incorrectly, leaving RTP media streams pointing at internal private addresses that the carrier cannot reach. The call signals successfully, the phone rings, the user picks up — and nobody hears anything. Every VoIP engineer has shipped a support ticket with “disable SIP ALG” in the first reply.
6. RTP Media Path: Jitter, Packet Loss & MOS
Once the signaling succeeds, voice travels as RTP packets over UDP. ISP micro-outages, QoS misconfigurations, or a saturated uplink will degrade Mean Opinion Score (MOS) and push jitter above 30 ms or packet loss above 1 %. Users describe it as “robot voice” or “choppy audio” — but the call is technically “completed” and shows as green in any basic monitoring tool.
7. STIR/SHAKEN Attestation
Under the FCC’s TRACED Act, originating carriers must cryptographically sign each call with an attestation level: A (full), B (partial), or C (gateway). If your SBC or carrier suddenly downgrades your attestation from A to B — which can happen after a trunk change, an IP reassignment, or a certificate rotation — your calls begin landing as “Spam Likely” on Verizon, AT&T, and T-Mobile. Answer rates collapse overnight. Voice SLA monitoring needs to track this as a first-class metric.
8. Carrier Spam Labeling & CNAM Delivery
Analytics engines — Hiya, TNS, First Orion, YouMail — apply labels independent of STIR/SHAKEN. A DID with low call volume, bursty dialing patterns, or a complaint history can be flagged “Scam Likely” even with A-level attestation. Separately, CNAM (Caller Name) dips against the LIDB can fail or return stale data, causing the wrong business name to appear on the called party’s screen. Both issues are invisible to the PBX.
9. PBX, IVR, and Answering Logic
The call finally arrives at your PBX — Asterisk, FreeSWITCH, 3CX, Kamailio, or a cloud UCaaS platform — where a dialplan error, a full queue, an expired holiday condition, or a broken IVR prompt can drop the call. This is the layer most teams already monitor, and it is the last place the failure can happen.
The Metrics That Actually Expose DID Failures
A green “PBX online” dashboard tells you nothing about any of the nine failure domains above. These five call-quality metrics do:
| Metric | What it measures | Healthy range | Failure domain it surfaces |
|---|---|---|---|
| ASR — Answer-Seizure Ratio | Answered calls ÷ attempted calls | > 60% | Spam labeling, wrong IVR routing, unanswered queues |
| NER — Network Effectiveness Ratio | Calls reaching destination network ÷ attempts | > 95% | Carrier, SIP trunk, DNS, SBC |
| PDD — Post-Dial Delay | Dial → first ringback tone (seconds) | < 4 s | Upstream routing, LRN dip, SIP latency |
| MOS — Mean Opinion Score | Perceived audio quality (1–5 scale) | > 4.0 | Codec, NAT, RTP path, jitter |
| CCR — Call Completion Ratio | Completed calls ÷ answered calls | > 98% | Mid-call drops, media-path faults, ALG mangling |
If you track only PBX uptime, you are watching one layer of a nine-layer stack.
How Phone Number Monitoring Maps to Every Link in the Chain
Because each of the nine failure domains has a different signal shape, catching all of them requires a platform built around the call path itself — not an “is the port open?” check. Phone Number Monitoring operates a synthetic-call infrastructure that places real inbound calls to your DIDs from real originating networks and captures the signaling, media, and application-layer outcomes end-to-end. Here is how each capability maps back to the failure domains above:
| Failure domain | Phone Number Monitoring capability | What the probe detects |
|---|---|---|
| 1. Carrier routing & ported-number errors | Accessibility Monitoring from multiple originating carriers and geographies | Fast-busy, intercept messages, and single-carrier failures that reveal stale LRN data, RespOrg mistakes, or FOC-window routing loops |
| 2. SIP trunk registration & auth | Basic Monitoring with SIP response-code capture | 403 Forbidden, 401 Unauthorized, 503 Service Unavailable — seen from outside the network, without relying on PBX SNMP |
| 3. DNS, SRV, ENUM resolution | Geographically distributed probes with independent DNS resolvers | TTL misconfiguration, DNSSEC failures, regional resolution outages |
| 4. Codec negotiation & SBC handshake | Response Time Measurement with per-call signaling metrics | 488 Not Acceptable Here responses, transcoding-induced quality collapse, PDD spikes |
| 5. NAT, SIP ALG & one-way audio | Line Quality Monitoring with bidirectional RTP analysis | One-way audio tagged as a specific failure class, not buried inside a generic “call failed” alert |
| 6. Jitter, packet loss & MOS degradation | Line Quality Monitoring with per-call MOS, jitter, and loss scoring | Audio-quality regressions before users complain; correlation with ISP, QoS, or peering incidents |
| 7. STIR/SHAKEN attestation drift | Multi-carrier origination across U.S. mobile and wireline networks | ASR asymmetry across carriers — a leading indicator of attestation downgrade or new spam filtering |
| 8. Spam / “Scam Likely” labeling & CNAM | Multi-carrier origination with caller-ID capture | Labels presented on the called device and wrong caller-name delivery from stale LIDB/CNAM dips |
| 9. PBX dialplan, IVR & answering logic | IVR Testing with DTMF navigation and prompt validation | Broken menus, expired holiday conditions, full queues, missed hand-offs to live agents |
Because every probe runs external to your network and across carrier-diverse origination points, the platform sees exactly what your customers see — not what your PBX thinks is happening.
What the Phone Number Monitoring Workflow Looks Like
Monitoring a DID does not stop at detection. A modern reliability workflow needs four things, and the platform is built around them:
- Continuous synthetic calls. Mission-critical DIDs are tested every 1–5 minutes from multiple originating networks (Verizon Wireless, AT&T, T-Mobile, wireline carriers, plus international PSTN for global numbers). Secondary DIDs run on looser intervals to control cost.
- Failure-domain tagging. Alerts arrive with the specific failure class — “one-way audio,” “488 codec mismatch,” “PDD > 6s,” “ASR drop from T-Mobile only” — so the on-call engineer knows which layer of the stack to investigate, not just that “the number is down.”
- Historical trend data. MOS, jitter, packet loss, ASR, NER, and PDD are stored per DID and per originating carrier. This is the evidence contact centers and compliance teams need to enforce voice SLAs and prove regulatory reachability over time.
- Automation hooks. API integration sends incidents straight into PagerDuty, Opsgenie, Slack, Microsoft Teams, or a custom webhook — and pulls raw call-quality data into Grafana, Datadog, or a data warehouse for correlation with network events.
DID Failures Phone Number Monitoring Catches in the Wild
A few patterns recur across deployments:
- The silent post-port outage. A healthcare network ported 22 clinic DIDs to a new carrier over a weekend. The FOC completed at 04:00 Saturday; by 06:30, Phone Number Monitoring probes originating from a regional wireline carrier were still reaching the old carrier because the LRN had not propagated. The on-call engineer was paged before the first patient dialed in Monday morning.
- The SIP ALG surprise. An SMB switched ISPs. The new router silently enabled SIP ALG. Inbound calls rang, agents answered — and nobody heard anything. Line Quality Monitoring flagged one-way audio as a specific failure class within two minutes, not the 45 minutes it would have taken a customer to call back a third time.
- The codec-mismatch MOS collapse. An upstream carrier maintenance window forced a renegotiation that dropped Opus support. Calls still connected but transcoded through G.729, collapsing MOS from 4.3 to 2.7. The MOS-threshold alert fired and the network team had a carrier ticket open before any user reported “robot voice.”
- The attestation downgrade. After an SBC certificate rotation, one regional carrier started delivering calls with B-level attestation — which T-Mobile labeled “Spam Likely.” ASR from T-Mobile origination points dropped 34% overnight while Verizon and AT&T held steady. The asymmetry surfaced within a single monitoring cycle.
None of these failures would have tripped an “is the PBX pingable?” dashboard. All of them were caught because end-to-end synthetic calls test the call path the way a customer experiences it.
Enterprise vs. SMB: Same Chain, Different Stakes
The failure chain is identical whether you run a ten-seat clinic or a 10,000-agent contact center, but the economics diverge sharply:
- Enterprise and regulated contact centers — A single hour of attestation downgrade on a sales DID can cost six figures in lost conversions. Compliance teams in financial services, healthcare, and insurance need an auditable record that every regulated hotline has been continuously reachable and that STIR/SHAKEN attestation has held at A-level. Voice SLAs against ITSPs are only enforceable with third-party monitoring data — which is exactly what Phone Number Monitoring’s historical records provide.
- SMBs and MSPs — The dollar loss per outage is smaller, but the margin of error is thinner. A roofing company missing three calls on a storm day loses the week. An MSP supporting dozens of small clients needs a single pane of glass that catches ported-number errors, SIP ALG issues, and misrouted after-hours queues across all of them — which is the multi-tenant use case Phone Number Monitoring is designed for.
In both cases the principle is the same: the customer should never be your monitoring system.
Frequently Asked Questions
What is VoIP DID monitoring?
Why do VoIP DID numbers fail when the phone system appears "up"?
How often should DID numbers be tested?
Can monitoring detect STIR/SHAKEN and spam-labeling issues?
How is Phone Number Monitoring different from a basic uptime check?
Stop finding out about broken DIDs from angry customers. Start a free trial of Phone Number Monitoring and get end-to-end visibility across every link in your VoIP call chain.
