Freeze one DID, one call and the effective configuration
Record the dialed DID, timestamp and timezone, account owner, primary route, DID POP hostname, authentication type, registration server, portal registration indicator where applicable, inbound number format, ring time, enabled Busy, Unreachable, No Answer and Max Capacity destinations, provider and PBX call identifiers, edge receipt, PBX match, answer, media and caller outcome. Redact credentials and personal numbers.
Classify the first disputed boundary: DID ownership, primary route, POP, identity, registration, provider attempt, delivered format, PBX match, failover state, answer or media. Do not change them together.
Prove DID ownership, primary route and POP alignment
Confirm that the DID is active on the intended account, export its current configuration and record the primary route and POP. Compare that POP hostname with the server or proxy actually used by the intended PBX identity. Preserve current DNS answers and response sources.
A registered subaccount does not prove that the DID points to that subaccount or POP. A portal registration indicator applies to credentialed SIP registrations and is not expected for IP-authenticated subaccounts.
Follow the provider attempt into the first PBX rule
Retain the provider target, source, transport, Request-URI, To identity, response or transport error and elapsed time. If the INVITE reaches the customer edge, record the endpoint or trunk that accepted it, the delivered NANPA or E.164 form, normalization, first matching inbound route and final destination.
Do not silently rewrite a POP mismatch as a DID-format problem or use a broad catch-all route to hide an unidentified request. Correct the earliest demonstrated owner.
Identify the exact failover state before editing it
Check Busy, Unreachable, No Answer and Max Capacity separately. Preserve the primary response, transport outcome, ring-time expiry or capacity evidence that could select each state. Unreachable can include registration or firewall trouble; No Answer requires a delivered call that remains unanswered; Max Capacity requires the configured caller threshold.
Record the alternate attempt and result. The reviewed pages do not publish one universal SIP-code map, retry count, restoration timer or established-call survival contract.
Use the echo-test route without losing the production baseline
If authorized, export the DID configuration, temporarily select the provider Sound Quality Test, call from an external number and record whether the provider application answers. Restore the original route immediately and confirm its effective value.
A successful echo test narrows the incident toward the customer route, registration, network or PBX. A failed echo test is provider-support evidence. Neither result proves production media, codec, DTMF, capacity or availability.
Retest normal routing, each approved fallback and restoration
Change only the demonstrated owner: DID route, POP, identity, registration target, firewall policy, inbound format, PBX match, ring time, capacity threshold or failover destination. Repeat an authorized new-call test for the normal path, each approved failover condition and return to normal. Record attempt order, PBX match, answer, two-way audio, clean release and caller treatment separately.
Remove temporary catch-all routes, captures and elevated logging. One successful call does not establish universal availability, capacity, emergency behavior, failover timing or compatibility. No VoIP.ms account, DID, route, PBX, network path, failover event or live call was inspected or tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- VoIP.ms DID routing, failover, POP and inbound format ↗
- VoIP.ms subaccount authentication and registration ↗
- VoIP.ms server and DID POP selection ↗
- VoIP.ms DID troubleshooting ↗
- VoIP.ms incoming-call troubleshooting ↗
- VoIP.ms registration troubleshooting ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.