Freeze one DID, one call and the effective route profile
Record the dialed DID, timestamp and timezone, inbound trunk group, assigned route profile, ordered destinations, destination types and targets, registration identity and Contact or Customer IP, ACL state, first provider attempt, response or transport result, any transfer attempt, 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 assignment, route profile, destination priority, registration, ACL, Customer IP, provider attempt, advancement, PBX match, transfer, answer or media. Do not change them together.
Prove the DID is assigned to the intended route profile
Export or capture the DID record and its selected route profile. Then record every effective destination and priority inside that profile. A route can exist without being assigned to the number, and the inbound trunk group can contain more than one route.
Do not use a working outbound call, registration indicator or saved PBX configuration as proof of number assignment. Start with the number and follow its actual profile outward.
Verify the selected destination identity
For Registered PBX, preserve the provider domain, successful REGISTER exchange, current Contact and any registration ACL decision. For Customer IP, preserve the configured static address, enabled state and route priority. A changed public IP can invalidate either an ACL-constrained registration or a static destination in different ways.
Keep outbound-group IP authorization separate from inbound route destinations. The Voxtelesys IP tutorial explicitly treats outbound and inbound trunk groups as different controls.
Follow the first attempt without assuming why it advanced
Retain the first target, provider source, request, response or transport error, elapsed time and any later destination attempt. Voxtelesys documents priority ordering and a transfer after a failed or unanswered primary destination, but the reviewed pages do not provide one complete SIP-response and timer matrix for every route type.
Escalate unexplained advancement or non-advancement with exact call identifiers and timestamps. Do not rewrite a deliberate rejection, broaden an ACL or add a catch-all PBX route merely to force a later destination.
Separate provider delivery, PBX handling and transfer media
If an INVITE reaches the customer edge, preserve its source, Request-URI, called-number form, transport, first PBX object or context, normalization, first matching inbound rule, destination and final response. Provider delivery does not prove that the intended extension, queue, menu or voicemail handled the call.
For a Transfer destination, also preserve the selected outbound trunk group, new PSTN leg, caller identity, answer and media. A cloud PBX remaining reachable can prevent a local-office Internet outage from selecting the transfer, exactly as the provider tutorial warns.
Correct the earliest mismatch and retest failure plus restoration
Change only the demonstrated owner: DID-to-profile assignment, destination priority, registration Contact, ACL, Customer IP, PBX route, transfer target or media path. Preserve the prior state and repeat an authorized new-call test for the normal path, the approved failure or no-answer state, the later destination and return to primary. Record provider attempt, PBX match, answer, two-way media, clean release and caller treatment separately.
Remove temporary routes, broad ACLs, captures and elevated logging. One successful new call does not establish established-call survival, universal availability, capacity, emergency behavior or future compatibility. No Voxtelesys account, 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.
- Voxtelesys DID and number routing ↗
- Voxtelesys SIP Trunk Registrar ↗
- Voxtelesys portal IP-address routing ↗
- Voxtelesys registration ACL ↗
- Voxtelesys failover transfer ↗
- Voxtelesys call records ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.