VoIP.info Troubleshooting

Verizon IP Trunking ported number reaches the wrong PBX route or redirect

Trace one moved number through cutover state, provider handling, optional group redirection, customer-edge receipt and the first loaded PBX route.

Reviewed 2026-10-20Verizon public product, implementation, service-document and rates pages reviewed October 20, 2026; the signed order and current implementation record govern, and no Verizon account, order, port, trunk, PBX group, redirect, VARRS design, packet, call, media stream, emergency result, price, availability, compatibility or support response was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one number, one call and the unexpected result

Record UTC and local time, ordered product and location, number, port or migration status, expected and actual destination, activation and cutover evidence, provider call identifier, observed edge source, delivered Request-URI and identities, PBX match, any PBX Group Unreachable or Call Forward Unreachable destination, and recent order or route changes. Redact credentials and reusable trust material.

Classify the first divergence: the number was not in the final cutover set; provider routing still differs; a configured group redirect acted; no matching INVITE reached the edge; the correct request matched another trunk or context; or the intended PBX route produced the wrong destination.

Separate native or test DID success from ported-number state

Preserve the activation result for Verizon-issued native or test DIDs, but do not use it as proof that the affected ported number completed cutover. Reconcile the authorized list, current provider inventory, firm or scheduled milestone when applicable, port or migration completion, and the provider record for the affected number.

If a change was made too close to the cutover or the account record conflicts with the authorized list, preserve that discrepancy and escalate it. Do not rebuild the PBX route to compensate for unresolved number ownership or provider routing.

Check provider continuity controls independently

Confirm whether the order includes VARRS, PBX Group Unreachable, Call Forward Unreachable or another named control. VARRS is described as redundant Verizon SBC capacity; a group redirect instead forwards eligible numbers to another telephone destination. An alternate answer therefore does not identify which mechanism acted or prove that the primary trunk recovered.

Preserve the exact covered group, destination and effective provider configuration. The public documents do not supply one common detection timer, retry-code matrix, precedence rule or restoration sequence for every order.

Match the provider attempt to the customer edge

Correlate the affected number, calling party, timestamp and provider identifier with an authorized edge capture. If no matching INVITE arrives, keep the correction with the provider route, cutover record, continuity control or access path. If it arrives, retain source, Request-URI, To, asserted identity, SDP and response sequence before changing the PBX.

A portal row, activation trace or provider completion is useful correlation evidence, but it does not prove that this customer edge received this request or that two-way media followed.

Follow the delivered identity through Asterisk or FreePBX

For PJSIP, preserve the identify match, endpoint, transport, context and current loaded objects. Then follow digit normalization and the first loaded inbound route that matches the delivered identity. In FreePBX, verify generated configuration as well as the GUI record; do not hand-edit generated files or swap trunks merely because a native test DID worked.

Keep number inventory, provider-selected leg, edge receipt, PBX match, route destination, answer and media as separate outcomes. Correct only the first demonstrated divergence and retain rollback state.

Retest the moved number and one unaffected control

After an authorized correction, retest the affected number and one unaffected control while recording provider handling, edge receipt, PBX match, answer and media independently. If a group redirect is involved, test only the approved condition and confirm restoration through the same evidence chain. Do not place an emergency call as an ordinary regression test.

If the correction requires Verizon or carrier action, retain the ticket and terminal status without promising timing. No Verizon account, port, trunk, PBX group, redirect, VARRS design, PBX, packet, call, 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.