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

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.

Reviewed 2026-10-18Current 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 testedAdvancedDocumentation based · not lab tested

Freeze one call before changing the firewall

Record the number, timestamp and timezone, inbound or outbound direction, Flowroute route and provider edge, PBX public and private addresses, SIP transport, final response, offer and answer SDP, configured public RTP range, observed RTP endpoints, packet counts by direction and decoded audio result.

A connected timer or successful SIP transaction is signaling evidence. It does not prove that either media stream reached the correct interface or that the payload decoded.

Separate signaling sources from Direct Media

Flowroute's current firewall requirements list the Oregon and Virginia proxy ranges for SIP signaling on UDP or TCP 5060. The same page states that Direct Media RTP may arrive from any source IP and targets the customer system's public media-port range.

Do not reuse the signaling proxy allowlist as the RTP allowlist. Also do not open unrelated destination ports: preserve the PBX media range, exposure boundary and reason for each rule.

Read the negotiated media path from SDP

Compare the c= address, m= port, media direction and selected payload in both offer and answer with the PBX external-media configuration and the addresses observed on the wire. A private address advertised toward the provider, an untranslated port, an inactive direction or a codec mismatch can each produce a different failure.

Configuration fields and SDP are intent evidence; only packets and decoded audio establish the observed result.

Pair edge and PBX captures

Capture narrowly around the same call at the public edge and, when authorized, on the PBX-facing interface. Match Call-ID, SDP ports, SSRC, sequence progression and packet direction. One-sided packets isolate an earlier network or policy boundary; packets on both sides without intelligible sound move the investigation toward payload, codec, endpoint or audio-device handling.

Redact telephone numbers, credentials, addresses and audio before sharing. Do not leave broad capture or logging enabled.

Keep TLS and RTP protection separate

Flowroute documents TLS for the customer-to-edge SIP signaling leg. That does not establish SRTP or protection beyond the provider edge. Preserve the negotiated SIP transport and certificate result separately from the RTP or SRTP attributes and observed packets.

Do not infer protection of the complete call path from a TLS configuration alone.

Correct the earliest mismatch and bound the result

Change only the first proven owner: route destination, public address advertisement, NAT translation, PBX media range, firewall destination rule, codec or endpoint audio path. Repeat the same authorized call and verify two-way decoded audio, then remove temporary rules and captures.

This result does not prove every Flowroute route, provider edge, carrier media source, codec, load condition, availability, compatibility or active-call behavior. No account, firewall, packet or live call was inspected for this guide.

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 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 trunks: number routes, PoP edge strategy and direct-media evidence

Separate number-route relationships, registration or Host/URI delivery, preferred provider edge, customer failover, signaling and direct RTP.

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 number does not use the intended route, PoP or failover path

Prove the number relationships, route type, preferred provider edge, first result, any later attempt, PBX handling and direct-media result.

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

Firewall rules for VoIP

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

Read guide →
Protocol reference

SDP for VoIP: read addresses, ports and media direction

Interpret the session description without confusing an offered parameter with a working network path.

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