One-Way or No Audio: RTP, NAT and Firewall Causes

When the call connects but one side cannot hear the other, the signalling worked and the media path did not. Almost always NAT, firewall or SDP addressing.

Why it happens (general VoIP)

SIP sets up the call; the audio itself travels separately as RTP on a range of UDP ports. The SDP in the INVITE and 200 OK tells each side where to send audio. If that address is a private one (for example 10.x or 192.168.x) or the firewall blocks the RTP ports, audio goes nowhere in one or both directions.

Common causes

  • Dialer behind NAT advertising its private IP in the SDP (missing external IP / NAT settings).
  • Firewall not allowing the RTP port range in both directions.
  • SIP ALG on a router rewriting SIP packets incorrectly — usually best disabled.
  • Codec mismatch, where the call connects but no common audio codec was negotiated.
  • Asymmetric routing where audio leaves from a different public IP than signalling.

How to diagnose

  • Inspect the c= and m= lines of the SDP in a SIP capture — the c= address must be your public IP.
  • Run an RTP capture during a test call to see whether packets arrive and leave.
  • In Asterisk/VICIdial, check externip/external_media_address, localnet and the RTP port range in rtp.conf, and that the firewall allows it.
  • Disable SIP ALG on edge routers and re-test.

At CallCenterBoost

Your trunk details state the signalling host and authentication method. Media handling and codec support are confirmed for your service during route-test review. If audio fails only on certain destinations while others are fine, report the prefixes in a VoIP Route ticket; if it fails everywhere, check NAT and firewall first.

Related pages

WhatsApp, Telegram and email remain available for pre-sales and general enquiries. Registered customers use the Client Support Portal ticketing system as their primary, trackable support method. Payments are accepted in cryptocurrency only.