VoIP.info Troubleshooting

AT&T IP Flexible Reach call uses the wrong trunk group or route

Trace one inbound number through its group, routing scheme, algorithm, selected group trunk group, customer edge and PBX route.

Reviewed 2026-10-20Current AT&T IP Flexible Reach product, implementation and 2026 explanatory pages plus the first-party 2021 product brief and 2019 Group Administrator Guide were reviewed October 20, 2026. The dated guide documents portal concepts and workflows but is not represented as a universal current account interface or entitlement. No AT&T account, enterprise, group, group trunk group, routing scheme, portal role, order, access circuit, PBX, SBC, number, packet, call, emergency result, price, availability, compatibility or support response was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one number, scheme and unexpected destination

Record UTC and local time, enterprise ID, group ID, affected number, expected and actual group trunk group, routing-scheme name, algorithm, member order or percentages, concurrent-call state, unreachable or Forward Always settings, provider call identifier, observed edge source and recent order or portal change. Redact credentials and reusable trust material.

Classify the first divergence: wrong group or number inventory; unexpected scheme membership; algorithm behavior; a full or unavailable member; an unreachable or unconditional forwarding action; no packet at the edge; or the correct request reaching the wrong PBX route.

Confirm the account objects and your portal permission

Use the current implementation record to identify the enterprise, group, assigned number, group trunk group and associated trunk call routing scheme. The 2019 guide says Group Administrators may see a scheme as View Only or not at all, while Enterprise Administrators manage it. Missing edit access is not proof that the scheme is absent or broken.

If the dated guide no longer matches the account interface, preserve the discrepancy and obtain the current provider workflow. Do not recreate a scheme or change the PBX to compensate for an unresolved ownership or permission question.

Interpret the configured algorithm with capacity state

For Linear, preserve the ordered members and the availability or capacity state that could advance selection. For Round Robin, preserve a bounded sequence rather than judging one call. For % Allocation, compare a sufficient authorized sample to the configured distribution without promising an exact short-window ratio. For Most Idle, preserve the active-call counts used for the decision.

A selected provider leg still does not prove customer-edge receipt or PBX acceptance. Correlate the provider identifier and timestamp with the matching edge capture before changing routing.

Check forwarding and unreachable actions independently

Preserve Forward Always, Unreachable Destination and its timer separately from routing-scheme membership. If an alternate number or destination answered, determine which control selected it rather than labelling every alternate path as failover.

The public materials do not establish one universal response-code matrix, health probe, retry count, timer precedence or restoration sequence. Use the account's effective record and provider evidence, and never infer established-call preservation from a successful new call on another path.

Follow the provider leg into the customer PBX

If no matching INVITE reaches the edge, retain the provider scheme, group trunk group and access evidence and keep PBX edits out of the first correction. If it arrives, preserve source identity, Request-URI, To and asserted identity, then follow PJSIP identify or trunk selection, context, normalization and the first loaded Asterisk or FreePBX route.

Portal reports and call-detail records can correlate the call, but they do not prove the packet reached the customer edge, the PBX selected the intended route, SDP agreed or two-way audio was decoded.

Correct one divergence and retest with controls

Change only the first demonstrated divergence: group or number ownership, scheme membership, algorithm inputs, capacity, an unreachable or Forward Always action, edge policy, digit normalization or the exact PBX route. Keep rollback state. Retest the affected number and one unaffected control while recording provider selection, edge receipt, PBX match, answer and media independently.

If the correction requires an Enterprise Administrator or AT&T change, preserve the authorized change and terminal provider status. Do not promise availability or timing. No AT&T account, portal change, PBX, packet, media stream, emergency result or support response 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.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.