VoIP.infoThe independent guide to business communications.
VoIP.info Provider research

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.

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

Start with the route object and DID relationship

Flowroute documents route objects separately from the relationship that assigns a route to a phone number. The documented route types are host, number, uri and sip-reg; a newly purchased number can begin with sip-reg as its primary type. Preserve the DID, route ID, type and value, then preserve the number's primary and failover relationship IDs from the same time window.

A route visible in the portal or a successful route-creation response proves neither that the DID references it nor that a failover relationship exists. Administrative success and one delivered call also remain different evidence.

Documented service facts

Reviewed 2026-10-21. Compare SIP trunk services →

Outbound authentication

Documented

Flowroute documents credential registration and static source-IP authentication as separate outbound choices. Preserve direction, selected PoP, approved source, egress address and Tech Prefix where applicable; neither choice assigns an inbound DID route.

SIP registration

Documented

SIP-REG inbound delivery depends on registration at the relevant Flowroute PoP. Host, URI and PSTN-number routes do not use that registration state, and an IP-authenticated PBX may not appear as registered in portal status.

Inbound delivery

Documented

Flowroute route objects and the DID primary or failover relationships that reference them are separate records. Documented types are host, number, uri and sip-reg; administrative creation or assignment success does not prove live delivery.

Inbound failover

Documented

For Host and URI routes, Edge Strategy selects the first provider PoP and other PoPs may follow. That sequence is separate from the DID failover relationship, which selects another route object; public documentation does not publish one universal advancement matrix.

Number and regional availability

Not verified

Flowroute publishes US and Canadian rate-center reach and porting language, but current inventory, number type, portability, address eligibility and activation timing were not checked against a dated order for the target account.

Audio codecs

Documented

Current Direct Media guidance says RTP may arrive from any source IP and targets the customer system public RTP range. PoP signaling ranges are not a universal RTP-source allowlist; preserve SDP, NAT, ports, packets and decoded audio.

T.38 fax

Documented

Flowroute says it offers T.38 fax. That service statement does not establish the direction, gateway behavior, switchover, ECM handling, page success or fallback for a particular PBX, ATA or document set.

Signaling and media encryption

Documented

Inbound TLS requires the documented URI route, TLS transport and publicly trusted certificate. Signaling transport, certificate validation and Direct Media remain separate; configuration does not prove handshake success or protected media.

Call-start capacity

Documented

Flowroute's public Voice and pricing pages state that inbound calling is not sold as a fixed simultaneous-call-path limit. That marketing statement is not a calls-per-second entitlement, guaranteed acceptance result, bandwidth allowance or account-specific concurrency commitment; establish those limits and rejection behavior for the actual order.

Emergency calling

Documented

Flowroute documents creating and validating an E911 address and assigning it to an eligible number. Address validation, number association, outbound caller identity, activation, callback routing and a provider-approved non-live test remain separate controls; the pricing page also distinguishes fees for improperly provisioned emergency calls.

Pricing model

Documented

The pricing page lists metered voice, number and E911 examples plus volume, monthly-plan and annual-term alternatives. These are dated public inputs rather than a quote; destination, number type, emergency service, forwarding, taxes, commitment and renewal terms require the applicable rate deck and order.

Administration and support

Documented

Current PoP guidance says to allow all listed signaling ranges for provider failover and load balancing. Preserve route relationship, Edge Strategy, DNS result, provider source, customer-edge receipt, PBX route and restoration as separate operational evidence.

SMS and MMS

Documented

Flowroute publishes separate messaging APIs and rates. A number being voice-enabled does not prove SMS or MMS eligibility, campaign or sender registration, webhook configuration, throughput, consent controls, retention or fees for the target use.

Interpret delivery according to the route type

A sip-reg route depends on the customer gateway registration at a Flowroute PoP. A host route identifies a static host or dynamic name, a uri route retains a SIP URI, and a number route creates another PSTN leg. Registration state is therefore relevant only to the registration-routed path; it is not a universal inbound health signal.

Preserve the exact route type before changing credentials, expiry, Contact, DNS, firewall or PBX configuration. A registered gateway, reachable host, syntactically valid URI and answerable public number are different observations.

Keep preferred PoP separate from DID failover

Flowroute documents an Edge Strategy for Host and URI inbound routes. A selected PoP is attempted first and other provider PoPs can be used afterward; that provider-edge sequence is separate from the DID's primary and failover route relationships, which can select another customer destination.

Record the route relationship, selected edge, provider source and customer destination for each attempt. Another provider source reaching the same route is not proof that the DID advanced to failover, while another customer destination is not proof that all current provider edges were reachable.

Allow current signaling edges without turning them into media rules

Current interconnection guidance says to allow all listed PoP address ranges for provider failover and load balancing. The connected-PoP and retirement guidance also distinguishes a registered PBX, which can appear in status, from an IP-authenticated PBX, which does not register. A missing registration-status row therefore is not by itself an outage.

Direct Media has a different boundary: Flowroute says RTP may arrive from any source IP and targets the customer system's configured public RTP range. Do not reuse signaling-proxy ranges as a universal media-source allowlist; retain SDP, NAT translation, negotiated ports, observed packets and decoded audio separately.

Keep inbound routing, outbound authentication and TLS distinct

Flowroute documents credential registration and static source-IP authentication as outbound interconnection choices. IP authentication requires the approved static address and documented dial-string treatment; it neither assigns an inbound DID route nor proves registration. Inbound TLS requires a URI route with the documented TLS transport and a publicly trusted certificate.

Preserve direction, transport, hostname, source address, Tech Prefix where applicable, certificate chain and name validation. A loaded certificate, configured URI, accepted source or completed digest exchange is not proof that the intended DID relationship delivered a call or that media was protected.

Correct the earliest demonstrated divergence

Align the DID inventory, route objects, primary and failover relationships, Edge Strategy, current PoP set, firewall state, provider attempt, customer-edge receipt, PBX match and media in time order. Correct the first unexpected state rather than broadening authentication, firewall or PBX rules to compensate for an unproved earlier failure.

After an authorized change, exercise an ordinary normal call, the approved failure condition and restoration. Record each layer separately. The public documents do not establish one universal response-code matrix, timer, retry count, active-call-survival result, availability promise or account-specific capacity.

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

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 →
Troubleshooting · 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 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.

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 →
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 →