VoIP.infoThe independent guide to business communications.
VoIP.info Troubleshooting

Flowroute inbound call uses the wrong PoP, route or failover path

Find whether a Flowroute call first diverged at DID assignment, route type, Edge Strategy, provider PoP, customer destination, firewall, PBX route or media.

Reviewed 2026-10-21Current first-party Flowroute and BCM One route, PoP, firewall, authentication, TLS and service documentation reviewed October 21, 2026. Current support pages retain their own update dates, including February and August 2026 PoP material; the account, order, accepted implementation and observed transaction govern. No Flowroute account, number, route, relationship, credential, source address, registration, DNS answer, PoP, firewall, certificate, PBX, packet, call, media stream, failover event, price, availability, compatibility or support response was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one call and classify the first divergence

Record UTC and local time, calling and called identities, expected primary and failover route IDs, route types and values, Edge Strategy, registrations, provider source, customer destination, first response or timeout, any later attempt, PBX route and media result. Redact credentials, tokens, certificates and customer addressing before sharing.

Classify the first unexpected fact: wrong DID relationship, wrong route object or type, unexpected provider PoP, no customer-edge receipt, another PBX match, or signaling success with one-way or missing media.

Prove both DID relationships before testing failover

Flowroute separates route creation from assigning primary and failover relationships to a number. Compare the current DID record with both referenced route IDs, route objects, types, values and effective change time. A 201 route-create response and a 204 relationship-assignment response describe different operations; neither proves live delivery.

If the DID does not reference the intended route, correct that relationship before changing the PBX. Do not infer a failover assignment from the working primary route.

Apply the health evidence for the actual route type

For sip-reg, retain the registration transaction and the PoP with which the gateway registered. For host or uri, retain the configured destination, DNS result and Edge Strategy. For number, retain the separate PSTN leg and its result. Do not diagnose a host, URI or number route by registration status.

For IP-authenticated outbound service, the lack of a registered-PBX status is expected and does not establish that inbound delivery failed. Keep outbound source authorization and inbound DID routing separate.

Separate Edge Strategy from the failover relationship

The preferred-PoP control applies to Host and URI routes and identifies the first provider edge to try; other Flowroute PoPs may be attempted. The DID failover relationship selects another route object. Correlate every provider source, relationship and destination in time order.

Allow all currently documented signaling ranges for the approved design. One reachable or allowlisted edge can explain a partial result but does not prove the alternate edges were accepted. Do not invent which SIP response, transport failure or timeout must advance the DID to failover when the public material does not publish a universal matrix.

Trace edge receipt through PBX routing and Direct Media

At the customer edge, preserve source and destination addresses, transport, Request-URI, To, asserted identity, Via, Contact, Call-ID, SDP and the response sequence. Then follow the loaded Asterisk or FreePBX identify, endpoint, context, digit normalization, inbound route, time condition and destination.

If signaling succeeds, inspect the public RTP range, advertised addresses, translated ports and packets in both directions. Flowroute Direct Media may arrive from any source IP, so a signaling-only source allowlist is not a safe universal media rule. Edge receipt, PBX answer and intelligible two-way audio remain separate.

Retest normal delivery, approved failure and restoration

After correcting only the first demonstrated mismatch, exercise an authorized ordinary call on the normal path, the approved failure state, the alternate path and return to normal. Record DID relationship, provider PoP, customer destination, PBX match, answer and each media direction for every stage. Remove temporary captures and broad rules afterward.

One bounded exercise does not prove every trigger, active-call survival, availability, capacity, compatibility or emergency behavior. No Flowroute account, route, edge, PBX, packet, call, failover event or media stream 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.

Continue your research

Provider research · Current first-party Flowroute and BCM One route, PoP, firewall, authentication, TLS and service documentation reviewed October 21, 2026. Current support pages retain their own update dates, including February and August 2026 PoP material; the account, order, accepted implementation and observed transaction govern. No Flowroute account, number, route, relationship, credential, source address, registration, DNS answer, PoP, firewall, certificate, PBX, packet, call, media stream, failover event, price, availability, compatibility or support response was inspected or tested

Flowroute trunks: inbound route, PoP, failover and media evidence

Separate route objects, DID relationships, route type, preferred provider edge, customer failover, outbound authentication, signaling and Direct Media.

Read guide →
Troubleshooting · Current first-party Flowroute and BCM One documentation reviewed October 18, 2026. The current support pages were updated August 27, 2026 and list the Oregon and Virginia PoPs, require all listed signaling ranges for provider-side failover and load balancing, and describe Direct Media as RTP from potentially any source IP to the customer system public media-port range. Older but still public first-party route documentation distinguishes route objects from each number's primary and failover relationships, registration from Host or URI delivery, and preferred inbound PoP selection from customer-destination failover. Documentation and examples are not observed tenant state. No Flowroute account, credential, number, route, registration, DNS answer, certificate, PBX, firewall, packet, media stream, invoice, emergency workflow or live call was inspected or tested

Flowroute call signaling works but audio is missing

Separate SIP completion from Direct Media by preserving SDP, public media ports, translated addresses, observed RTP sources, packet direction and decoded audio.

Read guide →
Hub · Provider records reviewed individually on their listed dates; account-specific terms and availability require direct confirmation

SIP trunk provider research

Compare the connection model, call routing, media support and cost structure of documented SIP trunk services.

Explore topic →
Guide

SIP trunk IP authentication

Understand source-address trust and the consequences of a WAN address change.

Read guide →
Guide

SIP trunk failover and redundant calling paths

Design alternate routing without assuming active calls will survive.

Read guide →
Protocol reference

SIP REGISTER explained

Understand contact bindings, authentication challenges and why registration does not prove calling works.

Read guide →
Reference · SIP standards; extension support depends on both peers

SIP DNS discovery: NAPTR, SRV and address records

Understand service selection and failover before hard-coding a SIP server IP address.

Read guide →
Protocol reference · RFC 3261 SIP, RFC 3711 SRTP, RFC 4568 SDP Security Descriptions, RFCs 5763 and 5764 DTLS-SRTP, and current Asterisk PJSIP documentation reviewed October 6, 2026; deployed endpoints, intermediaries, certificates and calls require direct verification

SIP TLS and SRTP: what each protects

Distinguish adjacent-hop signaling protection, SRTP media protection, SDES and DTLS-SRTP keying, and the actual termination points on every call leg.

Read guide →
Guide · Current Asterisk PJSIP object, outbound-registration, configuration-example and res_pjsip references reviewed October 1, 2026; no account, carrier, PBX, endpoint, registration, identifier, route, call, emergency workflow, media stream, capacity or failover path was tested

Plan and configure an Asterisk SIP trunk

Translate each carrier direction into explicit PJSIP objects, identification, restricted dialplan, retry policy and leg-by-leg acceptance evidence.

Read guide →
Guide · FreePBX 17 and current Asterisk res_pjsip documentation reviewed October 5, 2026; Sangoma's generic module pages are responsibility guides rather than an exact installed field map; no FreePBX host, module, account, credential, trunk, route, registration, number, identity, call, media path, failover, capacity, emergency workflow or compatibility was tested

Configure and verify a FreePBX 17 PJSIP trunk

Translate current carrier requirements into FreePBX-owned PJSIP trunk, route and identity controls, then verify the generated Asterisk objects and each call direction independently.

Read guide →
Guide

Firewall rules for VoIP

Define management, signaling and media access separately using actual deployment requirements.

Read guide →
Guide

NAT for VoIP: signaling and media addresses

Map each translation boundary and compare advertised destinations with reachable addresses.

Read guide →
Guide · Wireshark 4.x / current upstream tool documentation; inspect installed versions

VoIP packet-capture methodology

Select interfaces, time windows and paired capture points that distinguish network loss from missing evidence.

Read guide →
Troubleshooting · First-party Asterisk documentation and SIP standard reviewed September 30, 2026; FreePBX 17 terminology retained; no PBX, provider, number, route or live call test

Inbound VoIP calls do not reach the business

Trace carrier delivery, Asterisk endpoint identification, DID matching and the final destination without collapsing the boundaries.

Read guide →
Troubleshooting · Asterisk 22 LTS · FreePBX 17 / Debian 12 checks

One-way VoIP audio

Trace the missing direction from advertised media address to receiving endpoint.

Read guide →
Hub

VoIP troubleshooting

Use symptoms and evidence to isolate registration, routing, media and device faults.

Explore topic →