Flowroute number does not use the intended route, PoP or failover path

Freeze one number and both relationship assignments

Record the number, primary and failover relationship IDs, referenced route IDs, each route type and value, preferred PoP, registrations, DNS answers, first provider source, first destination result, any later attempt, caller treatment and restoration. Redact credentials and customer addressing before sharing evidence.

Flowroute documents route creation separately from assigning that route to a number. A route visible in the account does not prove the number references it as primary or failover.

Interpret the destination by route type

For sip-reg, prove registration with the intended current PoP. For host or uri, preserve the configured destination and preferred edge strategy. For number, treat the result as another PSTN call leg. Registration state, DNS reachability, a valid URI and an answerable public number are different health signals.

Do not transfer a successful outbound interconnection result to the inbound number assignment.

Separate provider-edge recovery from the number failover relationship

A preferred PoP controls the first Flowroute edge for Host or URI routes, and other provider PoPs can be attempted after an edge failure. The number's failover relationship selects a different route object. Preserve source edge, relationship and customer destination for every attempt.

A second provider source delivering to the same destination is not proof that the number advanced to its failover route; a second customer destination is not proof that every provider edge is reachable.

Do not invent the advancement trigger

The public documentation identifies primary and failover relationships but does not publish a universal matrix of SIP responses, transport errors, timeouts, retry counts or restoration intervals. Retain the first request, response or absence of response, elapsed time, any retry, later destination and final caller result.

Do not suppress a valid PBX response or lengthen a timer merely to force another branch until the exact incident and expected Flowroute behavior are established.

Prove audio after the selected route

The current Direct Media guidance says RTP can arrive from any source IP to the PBX public media range. After signaling reaches the intended route, retain SDP, translated addresses, negotiated ports, packet direction and decoded audio. Use the Flowroute missing-audio diagnostic when the selected route connects but sound is absent.

A provider attempt or SIP answer does not prove the PBX selected the intended application or received bidirectional media.

Retest normal path, approved failure and restoration

Correct only the earliest demonstrated mismatch, then repeat an authorized new call for the primary route, approved failure case, alternate path and return to normal. Preserve edge, destination, PBX route, response, SDP and media at each step.

One bounded exercise does not prove active-call survival, universal availability, capacity, emergency behavior, compatibility or every failure trigger. No Flowroute account or live call was tested for this diagnostic.

Do not confuse a route change with a media repair

A later route can receive signaling yet still fail on Direct Media. The Flowroute audio diagnostic preserves SDP, media ports and packet direction.