Flowroute trunks: number routes, PoP edge strategy and direct-media evidence

Freeze the number, route relationships and delivery type

Record the Flowroute number, primary and failover route relationship IDs, referenced route objects, route types and values, preferred inbound PoP, registrations, current DNS answers, customer public address, signaling result, SDP and audio result. Flowroute creates route objects separately from the number relationships that select them.

The documented route types are host, number, uri and sip-reg; sip-reg is the default primary type for a newly purchased number. A visible route object, owned number and successful outbound call do not prove the number points to that route.

Keep provider edge strategy separate from customer failover

For host or uri, a preferred inbound PoP chooses the first provider edge used for the route; Flowroute says other PoPs can be attempted if that edge fails. For sip-reg, inbound calls originate only from PoPs with which the customer gateway registers. A number route sends a separate call back to the PSTN.

Those provider-edge choices do not replace the number's separate failover-route relationship. Preserve edge source, route relationship and customer destination independently before concluding which layer recovered the call.

Use the current PoP inventory and DNS result

The current support page, updated August 27, 2026, lists US-West-OR and US-East-VA and says all listed ranges must be allowed to use provider failover and load balancing. The developer guide prefers NAPTR, then SRV, then A-record discovery, with direct IP use last.

Record the name actually configured, lookup type, answer set, TTL, selected address, transport and source range seen on the wire. A copied address, an old worldwide list or one reachable proxy is not proof that the PBX can receive from every currently documented provider edge.

Do not treat signaling ranges as a media allowlist

Flowroute's current firewall page separates SIP signaling on UDP or TCP 5060 from Direct Media. It says RTP can arrive from any source IP and targets the customer system's public RTP port range. The signaling proxy ranges therefore are not a universal RTP-source inventory.

Retain the offer and answer SDP, public and private address translation, selected media ports, observed RTP sources, packet counts and decoded audio in both directions. A 200 response or connected timer proves neither inbound media nor two-way intelligible audio.

Bound TLS to the customer-facing signaling leg

Flowroute documents TLS between the customer system and its edge proxies and says inbound TLS uses the route edge strategy plus a trusted certificate. It does not claim encrypted signaling through the PSTN or establish SRTP for a particular call.

Preserve the exact transport, hostname, certificate chain, name validation and negotiated session separately from the RTP evidence. Do not convert a configured sips: URI or a loaded certificate into proof of a successful handshake or protected media.

Change the earliest demonstrated owner and retest

If the number references the wrong route, fix that relationship before changing PBX media. If the right route reaches the edge, inspect PBX identification, Request-URI, dialplan match, SDP and RTP. If only one provider edge is allowed, correct the signaling boundary before changing failover timers.

Repeat one authorized new call through the normal path and the approved failure case, then verify restoration and remove temporary capture or firewall changes. The reviewed pages do not establish every advancement response, timeout, retry, recovery interval, active-call survival result, availability, compatibility or account capacity.

Trace Flowroute signaling and Direct Media independently

Use the missing-audio diagnostic after the number route and provider edge are known; SIP proxy ranges are not a universal RTP-source list.