Skip to content NEW BitVoice AI Agents now speak 22 Indian languages Learn more →
BitVoice

VoIP One Way Audio: Causes and a Step-by-Step Fix Checklist

Why one side of a VoIP call cannot hear: NAT, SIP ALG, blocked RTP ports, codecs. A checklist for the router, the PBX and the phone to fix one way audio.

IT engineer checking a network router beside an office IP phone

You place a call on your IP phone, the other person picks up, and you can hear them but they cannot hear you. Or the reverse. This is VoIP one way audio, and it is one of the most common support calls for any office phone system. The good news is that it almost always comes down to a short list of network settings. This guide explains why one way audio happens and gives you a step-by-step checklist for the router, the PBX and the phone.

Why VoIP one way audio happens

A VoIP call uses two separate streams of traffic:

  • SIP signalling: sets up and ends the call. It usually runs on port 5060 (UDP or TCP) or 5061 for TLS.
  • RTP media: carries the actual voice, one stream in each direction, over a range of UDP ports.

If the call rings and connects, SIP is working. One way audio means one of the two RTP streams is not reaching its destination. Something on the path is sending voice to the wrong address or blocking it.

The usual causes

CauseWhat goes wrongTypical sign
NAT with no public address setThe PBX or phone advertises its private IP (for example 192.168.1.10) in the call setup, so the far end sends voice to an address it cannot reachRemote phones or SIP trunk calls have one way audio, local calls are fine
SIP ALG on the routerThe router rewrites SIP messages and gets the addresses or ports wrongProblems start after a router change; calls drop after 30 seconds or so
RTP ports blockedThe firewall allows SIP but not the RTP port rangeCalls connect but are silent in one or both directions
Codec mismatchThe two ends cannot agree on a codec, or a transcoding step failsSilence on some calls only, often to one provider or one phone model
Strict media checks behind NATThe PBX accepts audio only from the address it expected, but NAT changed itOne way audio on some remote phones only
VPN or routing issueVoice return traffic takes a different path or is droppedProblems only for branch offices or remote agents on VPN

Step-by-step troubleshooting checklist

Work through these in order. Change one thing at a time and test a call after each change.

  1. Note exactly when it happens. Internal call between two desk phones, a call to a mobile over the SIP trunk, or only for remote users? Which side cannot hear? The pattern points to the cause.
  2. Test an internal call on the same network. If two phones on the office LAN have clear audio both ways, the phones and codecs are fine and the problem is at the network edge.
  3. Check the PBX public address. The PBX must know its public IP and which networks are local, so it puts the right address in calls that leave the building.
  4. Open the RTP port range. Find the RTP range set on the PBX and allow exactly that UDP range on the firewall, in both directions, towards the PBX.
  5. Turn off SIP ALG on the router. Most broadband and many business routers have it on by default. Disable it and reboot the router.
  6. Check codecs. Make sure the phone, the PBX and the SIP provider share at least one codec, such as G.711 (alaw for India) or G.729 if the provider asks for it.
  7. Check NAT keep-alive on phones. Remote phones should send keep-alive packets so the router does not close the path for incoming voice.
  8. Use STUN or TURN for remote users. Where phones or softphones sit behind home routers, a STUN server helps them find their public address, and TURN relays media when a direct path is not possible.
  9. Test again from the far side. Call from a mobile to a DID and from the IP phone to a mobile. Both directions should now work.

What to check on the router or firewall

  • SIP ALG (sometimes called SIP helper or SIP fixup): off.
  • UDP port forward or firewall rule for SIP to the PBX, only if you host the PBX for remote phones or trunks, and restricted to known provider or office IPs where possible.
  • UDP RTP range forwarded to the PBX, matching the PBX setting exactly.
  • UDP session timeout long enough (60 seconds or more) so idle streams are not cut.
  • If you have two internet lines, make sure voice traffic leaves and returns on the same line.

What to check on the PBX

On Voxdial IP PBX, these settings sit on the General SIP page:

  • External Address: your public IP. The Detect Network button fills it in for you, along with your local networks.
  • Local Networks: every internal subnet, including branch offices on VPN, so calls between them skip NAT rewriting.
  • RTP Port Range: the start and end ports for voice. These ports must be open on your firewall.
  • Strict RTP: improves security, but on some NAT setups it can cause one way audio. Test with it off if remote phones are affected.
  • STUN and TURN servers: for phones and browser softphones outside the office.
  • Audio codecs: tick the codecs you allow and drag them into your preferred order.

The Voxdial manual notes that a wrong External Address or blocked RTP ports are the most common causes of one way or no audio on remote phones, so start there.

What to check on the phone or softphone

  • SIP server address: use the public address or domain for remote phones, the local address for office phones.
  • NAT traversal / keep-alive: enabled for remote phones.
  • Codec list: at least one codec in common with the PBX.
  • Local SIP and RTP ports: leave on defaults unless your provider says otherwise.

For step-by-step phone settings, see our SIP phone configuration guide. BitVoice IP phones can also be set up automatically from the PBX with auto provisioning, which avoids typing mistakes.

Remote agents and work from home

Home routers are the most frequent source of one way audio. The Voxdial Contact Center agent console supports STUN and TURN for remote agents and shows a call quality monitor with jitter, packet loss and round-trip time, so a supervisor can tell a network problem from a headset problem. Our guide to VoIP call quality for remote agents covers bandwidth, Wi-Fi and headsets in more detail.

When it is not one way audio

Some symptoms look similar but have other causes:

  • Choppy or robotic voice: packet loss or jitter, not NAT. Check bandwidth and QoS.
  • Echo: usually the handset, a speakerphone or an analog line on a gateway.
  • Call drops at about 30 seconds: often SIP ALG or a missing acknowledgement reaching the PBX.
  • No audio at all, both ways: RTP fully blocked or a codec failure.

Need help tracing one way audio on your network? Talk to BitVoice support.

FAQs

What causes one way audio on VoIP calls?

Most often the PBX or phone is behind NAT and advertises a private IP address, the router’s SIP ALG rewrites the call wrongly, or the firewall blocks the RTP port range used for voice.

Should I turn off SIP ALG?

In most cases yes. SIP ALG on broadband and business routers often breaks call setup and causes one way audio. Turn it off and set NAT correctly on the PBX instead.

Which ports does VoIP need?

SIP usually uses UDP or TCP 5060 (5061 for TLS) and voice uses a UDP RTP range set on the PBX. Open the exact range configured on your PBX, not a guessed one.

Why do only remote phones have one way audio?

Remote phones cross two NAT routers, the home router and the office one. Set the PBX External Address and Local Networks, enable keep-alive on the phone, and use STUN or TURN if needed.

Share

Related articles

See BitVoice working on your calls

Book a demo and we'll map your call flows and suggest the right setup.