VoIP.info Troubleshooting

One-way VoIP audio

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

Reviewed 2026-10-30Asterisk 22 LTS · FreePBX 17 / Debian 12 checksIntermediateDocumentation based · not lab tested

Define the missing direction

Write down who cannot hear whom and preserve one exact call's time, endpoints, dialog identifiers and PBX channel or leg names. If the customer cannot hear the office, follow media sent by the office toward the customer. Avoid the ambiguous statement that the customer has no audio. Registration and a completed SIP dialog prove neither media direction.

One-way audio: find the missing hop
First identify who cannot hear. If packets do not leave the sender, inspect the device or media source. If they leave but do not arrive, inspect SDP, NAT and firewall. If they arrive, inspect playback and decoding.

Follow one missing direction. Repeat on each PBX call leg and verify hold and transfer after a repair.

Separate the endpoint from the path

Check mute, handset, speaker and selected headset before changing network settings. Compare an internal call, an external call and another endpoint on the same network. A working internal call narrows the investigation toward the path or policy that changes at the carrier or remote-network boundary; it does not identify that boundary by itself.

Follow offer, answer and packets

For every affected leg, read the final SDP offer and answer rather than the first SDP body alone. Record the advertised receive address, port, codec, direction attribute and media-security profile, then compare those destinations with packets observed at paired capture points. Determine whether the expected stream leaves its sender, reaches the PBX, leaves the PBX and reaches its receiver. On a relaying PBX, the carrier-facing and endpoint-facing streams can have different addresses, ports and SSRC values; evidence on one leg is not proof of the other.

RTP sequence numbers can expose gaps and timestamps describe sampling progression, but packet presence does not prove audible payload. With SRTP, visible headers and timing can still support path analysis while media content and successful decryption depend on the negotiated security context.

Map evidence to the control

In Asterisk 22, inspect the loaded endpoint and transport before changing topology-specific PJSIP options. rtp_symmetric sends RTP back to the address and port from which RTP arrived; force_rport concerns SIP response routing; rewrite_contact concerns later SIP requests; media_address changes the media address placed in SDP; and direct_media decides whether media may bypass Asterisk. These controls are not interchangeable. Check transport local_net and external media or signaling settings against the real interface and NAT boundaries. In FreePBX, use the supported GUI or generated configuration ownership path rather than pasting fragments into managed files. On a FreePBX-managed PJSIP system, use the FreePBX-specific media investigation to preserve GUI intent, generated state and loaded state before changing transport, endpoint or Strict RTP controls.

Capture narrowly and confirm

Use a bounded diagnostic window. Asterisk's pjsip set logger on exposes sensitive SIP and SDP, while RTP debugging can be high volume; restrict access, reproduce one authorized call and turn temporary logging off. If a capture shows no stream, first confirm the interface, mirror direction, filter, dropped-packet counter and direct-media topology.

Change only the setting supported by the evidence. Re-test both audio directions plus hold, resume and transfer because a re-INVITE or UPDATE can change the media path. Keep the firewall and intended media protection enabled. Registration, an answered call and a decoded packet capture remain separate acceptance states.

Check whether a completed in-dialog offer moved the stream

For Asterisk PJSIP, the direct-media guide follows re-INVITE or UPDATE, accepted SDP and observed RTP. The PBX can legitimately stop seeing packets after a successful direct-media move; an incomplete or rejected offer leaves the earlier session in force.

Use the Asterisk PJSIP address path when SDP and packets disagree

On chan_pjsip, use the wrong-media-address diagnostic to separate the advertised media destination, actual RTP source, symmetric return address, direct-media change and SIP Contact routing.

Trace the missing Asterisk WebRTC direction

When one side is a registered Asterisk WebRTC endpoint, the browser-media diagnostic keeps the selected ICE tuple and protected browser-facing stream separate from the PBX's other call leg.

Apply Zen’s documented signaling and media boundary

For a Zen Business Talk SIP call, use the provider-specific no-audio workflow to compare the actual SDP and packets with Zen’s published signaling address and UDP 20000–30000 media range.

Trace both Baresip device and network media boundaries

Use the Baresip symptom diagnostic to compare capture, playback, account overrides, negotiated addresses and RTP directions without changing devices, codecs and NAT controls together.

Check the exact channel stream before changing NAT

The Asterisk RTP value diagnostic proves leg, stream, bridge phase, SDP interval and capture direction before treating an address as wrong.

Keep IP Telecom signaling success separate from media

The IP Telecom service record requires SDP, RTP tuples, NAT, QoS and decoded audio from the authorized path; a successful trunk transaction or provider quality statement does not prove two-way media.

Keep Clearfly signaling and portal state separate from RTP

The Clearfly service record requires SDP, RTP tuples, NAT, QoS and decoded audio from the authorized path; a portal registration label or completed SIP transaction does not prove two-way media.

Keep Redcentric access and signaling separate from RTP

The Redcentric service record requires SDP, RTP tuples, NAT, QoS and decoded audio from the authorized current path; managed access, registration or a completed SIP transaction does not prove two-way media.

Do not use buffering to explain a missing media path

The Asterisk jitter-buffer diagnostic first proves RTP presence and direction; a read-side buffer cannot create packets that never reach the channel.

Do not confuse CommPeak registration with media success

The CommPeak service record keeps registration or peer state separate from SDP, NAT, RTP tuples, firewall state, loss, jitter and decoded audio on each authorized direction.

Inspect every Voximplant media boundary

The Voximplant provider record keeps platform codec support separate from each negotiated offer, answer, transcode point, encryption profile, RTP tuple, firewall state and decoded direction.

A media wait can reveal the wrong or silent call leg

The silence and noise diagnostic proves received frames on the exact waiting channel before any duration or timeout change.

Observe the TelVox media path behind successful call state

TelVox call status can reach in-progress or completed without documenting the negotiated codec, RTP tuples, SRTP or decoded user result. The provider record requires path-specific SDP and media evidence before attribution.

Compare VoIPstudio device state with each RTP direction

VoIPstudio separates microphone, call output and ringer selections. Use the desktop diagnostic to correlate those controls with current network policy, SDP and packet direction before changing SIP ALG or firewall rules.

Prove the rewrite before blaming SIP ALG on VoIP Much calls

VoIP Much warns that SIP ALG can cause one-way audio and dropped calls. Its focused workflow requires the altered signaling, SDP or packet path to be demonstrated before network policy changes.

Separate VoIPline network claims from the failed media path

The VoIPline workflow requires the actual SDP, addresses and packet directions before network-policy changes.

Correlate Webex device selection with both media directions

The Webex App diagnostic records ringer, speaker, microphone, processing, SDP where accessible and per-direction statistics before changing network policy.

Expect Anveo Direct RTP to differ from signaling

Anveo Direct does not proxy RTP. Use the focused diagnostic to compare SDP and observed carrier media without treating the signaling allowlist as the RTP source list.

Do not confuse an AVOXI routing pass with media success

A passing URI test or accepted INVITE does not prove RTP in both directions. The AVOXI diagnostic carries the call into SDP and decoded-audio evidence.

Apply the Flowroute Direct Media boundary

Flowroute signaling sources and RTP sources are different evidence sets. The Flowroute diagnostic pairs SDP with edge and PBX packet direction.

Yay.com inbound SRTP requires both sides to agree

The Yay.com workflow separates TLS, dashboard encryption, SDP, SRTP packets and decoded audio.

Sinch signaling and media use different current ranges

The Sinch diagnostic separates SIP, TLS, SDP, SRTP and both RTP directions.

Trace the SIPTRUNK direct-media leg independently

The SIPTRUNK diagnostic separates successful SIP from the first RTP packet and decoded audio in each direction.

Trace V52 microphone and speaker directions independently

The V52 diagnostic follows microphone detection to far-end receipt and meeting receive to speaker output as different paths.

Trace V72 microphone and speaker directions independently

The V72 diagnostic follows microphone detection to far-end receipt and meeting receive to selected speaker output as different paths.

Keep Flowroute Direct Media separate from signaling success

The Flowroute guide distinguishes PoP signaling ranges from the public RTP destination range and observed media in each direction.

Check Colt SDES and unsupported MKI

The Colt-specific diagnostic traces TLS, SDP crypto and RTP or SRTP independently in both directions.

Separate Gamma route success from media success

The Gamma-specific diagnostic traces signaling, SDP and RTP in each direction.

Expect Commio media to follow the observed SDP

The Commio diagnostic keeps signaling proxies and direct carrier RTP sources distinct.

Apply the FreeSWITCH media mode to the observed RTP path

The refreshed FreeSWITCH media guide explains why bypass media removes the server from RTP while signaling remains anchored.

Map Trio C60 media to the selected owner

Before changing NAT or codecs, determine whether OpenSIP, Teams, a USB host, Bluetooth device or paired room system owns the call and preserve both media directions.

Keep Cloudli signaling and media evidence separate

The Cloudli diagnostic preserves SDP, translated RTP tuples and each decoded direction after signaling succeeds.

Follow Orange RTP or SRTP on each side of the eSBC

The Orange Business Talk diagnostic records negotiated SDP, actual tuples and each decoded direction rather than inferring media from signaling.

Follow Vodafone media in each direction

The Vodafone Evolved Voice diagnostic records SDP, actual RTP or SRTP tuples and decoded directions after signaling succeeds.

Follow Swisscom media in each direction

The Swisscom Enterprise SIP diagnostic records SDP, actual RTP tuples, SBC anchoring, transcoding and decoded directions after signaling succeeds.

Follow Sunrise media in each direction

The Sunrise Business Voice SIP diagnostic records SDP, RTP tuples, firewall treatment and decoded directions after signaling succeeds.

Follow Proximus media through every demarcation

The Proximus Business Trunking diagnostic records SDP, RTP tuples, firewall treatment and decoded directions after signaling succeeds.

Include intentional PBX stream mute in one-way-audio evidence

The MuteAudio diagnostic checks exact channel direction and restoration before changing NAT or codecs.

Follow Crazytel media independently of signaling

The Crazytel SIP trunk diagnostic records SDP, codec, RTP tuples, NAT treatment and decoded directions after answer.

Do not diagnose MaxoTel ALG or NAT from symptoms alone

The MaxoTel SIP trunk diagnostic preserves signaling, mappings, SDP, RTP directions and decoding for the same call.

Do not diagnose Aussie Broadband media from answer alone

The Aussie Broadband SIP trunk diagnostic keeps SDP, RTP directions, decoding and audibility attached to the same call.

Leave Wave login and notification state before RTP analysis

The Grandstream Wave diagnostic hands an answered call to SDP and packet-direction evidence rather than changing identity or notification settings.

Hand an answered RingCentral call to leg-specific evidence

The RingCentral diagnostic compares each leg, packet direction, decoding and audible result instead of relying on an overall quality label.

Do not diagnose Symbio media from answer alone

The Symbio Enterprise SIP trunk diagnostic keeps SDP, SRTP or RTP directions, decoding and audibility attached to the same call.

Do not diagnose Telstra media from answer alone

The Telstra SIP Connect diagnostic aligns access, SDP, packet directions, decoding and audibility for one call.

Trace MetTel media beyond the datasheet codec list

The MetTel SIP trunk diagnostic keeps SDP, RTP directions, decoding and listener result aligned to one call.

Trace NUSO protected media end to end

The NUSO diagnostic keeps TLS, SDP, SRTP negotiation, packet directions, decoding and listener results distinct.

Trace the exact Telesystem access and media path

The Telesystem diagnostic keeps ESBC or direct peer, SIP, SDP, packet directions, decoding and listener results distinct.

Trace the selected TPx access and media path

The TPx diagnostic keeps access, SIP, SDP, packet directions, decoding and listener results distinct.

Trace the selected Lingo media path

The Lingo diagnostic keeps access, SIP, SDP, packet directions, decoding and listener results distinct.

Trace the selected Voyant media path

The Voyant diagnostic keeps access, SIP, SDP, packet directions, decoding and listener results distinct.

Trace the selected Windstream media path

The Windstream diagnostic keeps access, SIP, SDP, packet directions, decoding and listener results distinct.

Trace the selected Granite media path

The Granite diagnostic keeps SIP, SDP, packet directions, decoding and listener results distinct.

Trace the selected FirstLight media path

The FirstLight diagnostic keeps SIP, SDP, packet directions, decoding and listener results distinct.

Map GAC2570 media to the selected owner

Determine whether the GAC2570 SIP stack, a controlled GVC system or an external host owns the session, then align signaling, device selection, packets and listener results.

Watch the explanation

Detecting Packet Loss in RTP Phone Calls Using WiresharkPlaintext Packets · 13:43 · Conceptual

Compares an intact RTP capture with a copy containing deliberately removed packets. The stream list and detailed analysis show how gaps become loss indicators and how burst patterns differ from scattered loss.

Read applicability and editorial notes →
Watch this video here

A 2024 Wireshark demonstration; menu placement can change. The second capture is a teaching fixture with simulated loss. Review used the available transcript and primary references; audio and screen readability remain unverified.

The player loads only when you choose Watch here. Playback uses YouTube’s privacy-enhanced embed; YouTube processes playback data.

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.