Darwvin

One-way audio or no audio on VoIP calls: causes and step-by-step fixes

Fix one-way or no audio on VoIP calls by checking SDP addresses, SIP ALG, blocked RTP ports, symmetric RTP, codecs and hold, with captures and Asterisk fixes.

Published 11 min read

One-way audio means one party hears the other while the reverse path fails, and no audio means neither direction works. SIP only sets up the call. The voice travels in a separate RTP stream whose addresses and ports come from the SDP inside the SIP messages, so many causes reduce to an address or port the other side cannot reach. This runbook sorts the symptoms by direction, then checks the SDP, the NAT and firewall path, SIP ALG, codecs and hold handling, using one capture to confirm each step.

Signaling and media travel separately

SIP messages such as INVITE and 200 OK carry a session description, and it tells each side where to send media. The c= line gives the connection address (RFC 4566 section 5.7) and the m= line gives the port. Audio then flows as RTP over UDP, conventionally on an even port with RTCP on the next odd port (RFC 3550 section 11). The SDP can signal otherwise, and rtcp-mux puts RTCP on the RTP port (RFC 5761). A call can signal perfectly and still carry no audio if these addresses are wrong.

Here is the offer from a phone at 192.168.1.20:

v=0
o=alice 2890844526 2890844526 IN IP4 192.168.1.20
s=-
c=IN IP4 192.168.1.20
t=0 0
m=audio 16384 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=sendrecv

The address 192.168.1.20 is in a range RFC 1918 reserves for private networks (section 3). The far end sends its audio there, the public internet cannot route it, and the phone never receives the other side. One line like this is enough to produce one-way audio.

Work out the direction first

What you hearLook here first
You hear them, they cannot hear youTheir SDP, the address and port you send to, and their inbound firewall
They hear you, you hear nothingYour SDP, the address and port they send to, and your inbound firewall
Audio returns only after a hold or transferThe hold and resume SDP: sendonly, inactive, sendrecv
Silence before answer, audio afterThe 183 response and whether its SDP is played
Only some calls, one route or one device typeCodecs in the SDP of a good call compared with a bad call
Only one computer or phoneLocal audio devices, network interface and VPN

Media goes to the address the other side advertised, so start with the SDP.

Causes and fixes

1. Private or wrong addresses in the SDP

Phones behind NAT advertise their LAN address unless something rewrites it, so the PBX or SBC must advertise a public media address. In Asterisk's PJSIP transport, local_net marks the internal subnet, and external_media_address and external_signaling_address set the addresses the server advertises. The option names come from the official sample:

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0
local_net=192.168.1.0/24
external_media_address=203.0.113.10
external_signaling_address=203.0.113.10

After the change, the c= line in the server's 200 OK should show the public address.

2. SIP ALG

SIP ALG is a router or firewall feature that inspects SIP and rewrites it. Andrews & Arnold's support page says it can cause one-way audio, no audio or failed registration. SonicWall's knowledge base lists one-way audio among the symptoms that disabling SIP ALG can resolve (as of October 2026). Turn SIP ALG off in the NAT or application-layer settings and retest, because the menu name varies by vendor. If the device has no switch, put the phone or PBX behind a router that does not inspect SIP. To confirm the ALG is the cause, compare the Via, Contact and SDP addresses leaving the phone with those arriving at the far end. Any change means something on the path rewrote them.

3. Blocked RTP ports

SIP uses port 5060, or 5061 for TLS (RFC 3261). RTP uses UDP ports chosen for each call, so a firewall that opens only the SIP port passes call setup and blocks the audio. Asterisk's rtp.conf sample sets rtpstart=10000 and rtpend=20000 and states that the built-in defaults are 5000 and 31000 (as of October 2026). Choose one range, configure it on the PBX, and open exactly that range:

[general]
rtpstart=10000
rtpend=20000

On a Linux firewall, list the current rules with sudo nft list ruleset or sudo iptables -S, then allow the range, ideally only from the provider's address block:

sudo iptables -A INPUT -p udp --dport 10000:20000 -s 203.0.113.0/24 -j ACCEPT

Do not open the whole UDP range to the internet to get audio working.

4. Asymmetric RTP and strict RTP

RFC 4961 defines symmetric RTP: a device sends RTP from the same UDP port it receives on. NAT mappings are created by outbound packets, so media sent from another port may not match the mapping. For PJSIP endpoints behind NAT, rtp_symmetric=yes enforces symmetric RTP, and force_rport=yes makes Asterisk use the return port for responses (RFC 3581 section 4). The sample pairs these options for far-end NAT and firewalls.

Strict RTP can drop audio too. Asterisk's rtp.conf sample says strictrtp is enabled by default and that it "will drop RTP packets that do not come from the recognized source of the RTP stream." The sample describes probation as the number of packets needed to change the RTP source address, and advises changing it if RTP is dropped after a call connects. Tune probation before you disable strictrtp.

5. Codec and payload mismatch

The answer decides the codec, and each side must send only payload types the far end declared. If the far end cannot decode the codec, you get silence or garbled audio. That is different from a rejected call, where the answer carries port 0 or a 488, covered in the SIP response codes reference. Keep G.711 enabled on both legs as a fallback: PCMU and PCMA are static payload types 0 and 8 (RFC 3551 section 6). Opus uses a dynamic payload type from the SDP (RFC 7587 section 4.1), so an Opus-only leg needs Opus on the other side or a transcoder. For codec choice, see VoIP codecs compared.

6. Hold and re-INVITE handling

RFC 3264 section 8.4 puts a sendrecv stream on hold by marking it sendonly, and a recvonly stream becomes inactive. Resuming means sending sendrecv again. If the resume re-INVITE is lost or mishandled, one side stays on hold and the call remains one-way. Re-INVITEs can also move media directly between phones, called direct media. If a phone behind NAT is one of them, the other phone sends RTP to a private address. The NAT example in the official pjsip.conf sample sets direct_media=no.

7. Early media

A 183 can carry SDP, because provisional responses may contain session descriptions (RFC 3261 section 21.1). That SDP lets the network play ringback or an IVR prompt before answer. If the phone ignores it, the caller hears silence until the call is answered. Capture the 183 and check for an SDP body before you change any RTP settings.

8. Local causes

Rule out the computer or phone first: microphone and speaker selection, mute, Bluetooth routing and any VPN. A VPN or a second network adapter can make the client advertise an address the far end cannot reach. On Linux, ip route get shows the source address the system will use for a destination:

ip route get 203.0.113.10

If src is not the address your PBX expects, bind the softphone to the right interface or fix the route.

Capture both legs

Capture on the phone or on the PBX. This filter matches SIP and the RTP range from the configuration above:

sudo tcpdump -i any -n -s 0 -w call.pcap 'udp portrange 10000-20000 or port 5060'
sngrep -I call.pcap

sngrep shows each SIP call as a flow, and opening a message shows its headers and SDP. In Wireshark, filter on rtp, then open Telephony, RTP, RTP Stream Analysis for per-stream statistics such as maximal jitter. The RTP Streams window lists every RTP stream in the capture, so you can see whether media flows both ways.

On Asterisk, enable debugging from the CLI for one call and turn it off afterwards, because the output is verbose. Use pjsip set logger on and rtp set debug on, and the matching off commands. On the Linux desktop, Darwvin Softphone (Early Access) shows a SIP message ladder and RTP stream analysis, so signaling and media sit in one window.

What the capture shows

In the captureWhat it meansFix
c= or m= holds a private address, and RTP goes thereThe far end cannot reach itExternal addresses on the PBX, SIP ALG off
RTP leaves from a port other than the one in m=Asymmetric RTP, so the NAT mapping points elsewherertp_symmetric and force_rport, or the phone's NAT setting
The answer has m=audio 0The stream was rejected (RFC 3264 section 6.1)Codec or encryption match
The resume still has a=sendonly or a=inactiveHold was never releasedHold handling and direct_media=no
RTP leaves but nothing returnsInbound UDP is blocked or the NAT mapping expiredOpen the range and check NAT timeouts

Runbook, step by step

  1. Name the symptom: which direction, when it starts (before answer, after answer, after hold or transfer), and whether every call is affected.
  2. Rule out the local side: microphone, speaker, mute, Bluetooth, VPN and ip route get.
  3. Capture one failed call on the endpoint or the PBX.
  4. Read the SDP in the INVITE and the 200 OK. Are the addresses public? Is any port 0? Which codecs are listed?
  5. Check which way RTP flows. If yours leaves but nothing arrives, the far end's advertised address or the inbound path is wrong. If nothing leaves, check the SDP, codecs and hold state.
  6. Fix the matching cause above, one change at a time.
  7. Retest with a call to a second device, and capture again.

Asterisk and FreePBX settings

For PJSIP endpoints behind NAT, the official sample's NAT example combines these options:

[1001]
type=endpoint
transport=transport-udp
context=internal
disallow=all
allow=ulaw,alaw
direct_media=no
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes

The sample notes that rewrite_contact=yes is needed when the endpoint does not know its own public address and port. FreePBX exposes NAT and external-address fields in its SIP settings, but the names and locations change between releases, so follow your version's administration guide. For the PBX setup itself, see connecting a softphone to FreePBX or Asterisk.

Routers and firewalls

Turn off SIP ALG. Open only the RTP range you configured, limited to the provider's addresses where possible. Forward the PBX's ports rather than a range to a client phone, and do not expose phones directly to the internet to get audio working.

FAQ

Why can I hear them but they cannot hear me?

Their audio reaches you, so the fault is on the path from you to them. Check the address and port in their SDP first, then whether your phone sends from the port it advertised, and whether their firewall allows inbound RTP.

Is one-way audio a SIP problem?

Not necessarily. The call setup can succeed while the media path fails, because SIP and RTP are separate. A SIP ALG or a SIP-aware firewall can still edit the signaling and break the media, so check SIP settings as part of the diagnosis.

Do I need port 5060 open for audio?

No. Port 5060 carries SIP. Audio uses UDP ports chosen for each call and advertised in the SDP, from the RTP range the PBX is configured to use (RFC 3550 section 11).

Can a VPN cause one-way audio?

Yes. If the phone binds to the VPN interface or advertises a VPN address, the far end sends audio to an address it cannot reach. Check the source address with ip route get, then bind the client to the right interface.

Should I turn off SIP ALG?

If the router has it and the symptoms match, test with it off. SonicWall's knowledge base and Andrews & Arnold's support page both recommend trying audio with SIP ALG disabled.

References

Get product news by email

We use your address only for these emails. The unsubscribe link is in every email. Read our privacy policy.