Silent calls and one-way audio in VoIP: causes and how to fix them

What is a silent call and what is one-way audio?

A silent call is a VoIP call that connects with no audio in either direction: nobody hears anybody. One-way audio is a call in which one side hears and the other doesn’t. In both cases the SIP signaling worked; what failed was the audio path, the RTP stream.

The industry terms are no-way audio and one-way audio. One-way audio means one direction found its path and the other didn’t, which almost always points to an address, NAT or firewall issue on one specific side. A silent call usually points to something that affects the whole stream: the codec, encryption, a port range closed in both directions or media marked as inactive.

On an 0800 (toll-free) number or an IVR, a call that connects and stays silent is worse than a rejection: it shows up as answered and no completion alarm fires.

Why does the call connect but the audio doesn’t get through?

The call connects and the audio doesn’t get through because a VoIP call uses two separate paths. SIP (RFC 3261) negotiates the call; the audio travels in RTP (RFC 3550), on UDP ports chosen on the fly. The 200 OK proves SIP got through, but it doesn’t prove RTP can reach the announced address and port.

The audio address travels inside the SIP message itself, in the SDP body. Under the offer/answer model in RFC 3264, the caller offers an address, a port and a list of codecs; the answering side responds with its own. Each side sends audio to the address the other announced. An example of an offer from a PBX behind NAT:

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

The c= line says where to send the audio, and the m= line says which port and which codecs. In this example, the PBX announced 192.168.1.20, a private address. The carrier, on the outside, sends the audio to that address, which doesn’t exist on the internet, and the audio disappears. The PBX, in turn, sends its audio to the public address the carrier announced, and that direction works. Result: the carrier hears the extension, and the extension doesn’t hear the carrier.

The a=sendrecv line matters too. The sendonly, recvonly and inactive attributes deliberately limit the direction of the audio, for example on a call on hold. An inactive left over from a hold or a transfer that didn’t complete cleanly can leave the call silent with the entire network working.

What are the most common causes of silent calls and one-way audio?

The most common causes of silent calls and one-way audio in VoIP are eight: unhandled NAT, a SIP ALG rewriting the SDP, a blocked RTP range, the wrong external IP in the SDP, no symmetric RTP, an incompatible codec, SRTP on one side only and mishandled early media. The table summarizes the symptom of each.

Cause	Typical symptom	Where to check
Unhandled NAT	One-way audio, almost always outside-to-inside	The address on the c= line of the SDP the PBX sends
SIP ALG on the router or firewall	Symptoms that change from call to call, registrations that drop, calls that drop at around 32 s	The SIP or VoIP options on the router or firewall
RTP range blocked or not forwarded	Silent or one-way calls, only on calls through the trunk	Inbound rules and UDP port forwarding
Wrong external IP in the SDP	Inbound audio disappears, sometimes only after an IP or link change	external_media_address in PJSIP, externaddr in chan_sip
No symmetric RTP	One-way audio with remote phones or with the far end behind NAT	rtp_symmetric and force_rport on the endpoint
Incompatible codec	Rejection with SIP 488, or a call that connects with silence or noise	The m= and a=rtpmap lines of the offer and the answer
SRTP on one side only	Silent in both directions, or rejection with SIP 488	The RTP/SAVP profile in the SDP and media encryption on the endpoint
Early media	Silence before the answer: no ringback and no carrier announcement	183 Session Progress with SDP

Unhandled NAT

NAT swaps the PBX’s private address for the link’s public address in the IP headers, but it doesn’t touch the content of the SIP message. The SDP still says 192.168.1.20, and the far end believes it. RFC 4787 describes how NATs handle UDP, with different mapping behaviors depending on the destination, and RFC 6314 collects the NAT traversal practices for SIP: announce the public address, reply to the port the message came from, keep the mapping alive with periodic messages and use symmetric RTP. Phones and adapters behind NAT can also discover their own public address with STUN (RFC 8489).

A SIP ALG rewriting the SDP

The SIP ALG is a feature of many routers and firewalls that reads SIP messages, swaps private addresses for public ones inside SIP and the SDP, and opens RTP ports on demand. When the PBX already announces the external address, the two corrections stack; when the ALG rewrites only part of the message, for example the Contact header but not the c= line, the result is an inconsistent SDP. The ALG also can’t read SIP over TLS, because the message is encrypted. That is why the usual advice is to turn it off and handle NAT in one place only.

RTP port range blocked or not forwarded

Each RTP stream uses one UDP port, and under RFC 3550 the matching RTCP uses the next port up. The PBX picks ports from a configured range, and the firewall has to let that entire range through to it. Partial forwarding produces an intermittent fault: calls that land on a port inside the forwarded part work, and the rest are silent.

Wrong external IP in the SDP

Configuring the external address fixes NAT until the address changes. Links with a dynamic IP, a backup link that takes over when the main one fails, or an outbound route over a different link from the one announced all make the PBX announce an address that isn’t the one traffic actually leaves from. The same goes for the list of local networks: Asterisk only swaps the private address for the public one for destinations outside the networks listed as local. An internal network missing from the list, such as a branch office VPN, gets the public IP and ends up with one-way audio.

Symmetric RTP

Symmetric RTP means sending and receiving audio on the same port and, on the other side, sending audio back to the address and port it actually arrived from, ignoring what the SDP said. It is the most robust way to traverse a NAT you don’t know, and it is one of the practices in RFC 6314. When the far end, a remote phone or a carrier behind NAT, announces an address that doesn’t work, only symmetric RTP on your side gets the audio to it.

Incompatible codec

If the offer and the answer share no voice codec, the call is usually rejected with SIP 488 Not Acceptable Here. The harder case is the call that connects: one side accepts a codec it can’t handle, a codec transcoding fails on the PBX, or the codec list changes in a re-sent SDP. The call shows as answered and stays silent or noisy.

SRTP on one side only

With SRTP, the audio is encrypted, and the SDP announces the RTP/SAVP profile instead of RTP/AVP. If one side requires encryption and the other sends plain audio, or if the keys weren’t agreed, the packets arrive and are discarded. The call is silent in both directions with normal packet counters. Under RFC 3264, a rejected media stream comes back in the answer with port 0, and that detail in the SDP is usually the clue.

Early media

Early media is audio that arrives before the answer: ringback generated by the network or the carrier’s announcement saying the number doesn’t exist. It comes with a SIP 183 Session Progress carrying SDP, and RFC 3960 describes how that early audio is handled. If the PBX, the firewall or the phone doesn’t let that audio through, the caller hears silence until the answer, and a call that fails with a recorded announcement seems silent. An SDP in the 183 that differs from the SDP in the 200 OK can also leave the audio pointed at the wrong place after the answer.

How does the symptom point to the cause?

The symptom of a silent call or one-way audio points to the cause once you look at which direction the audio fails in, at what point in the call and on which calls. A fault on every inbound call is different from one that shows up on one call in three.

Symptom	Likely cause	First check
The extension can’t hear the outside party; the outside party hears the extension	Private IP in the SDP, SIP ALG, inbound RTP range closed	The SDP the PBX sends and the port forwarding
The outside party can’t hear the extension	Restricted outbound UDP, or the far end’s SDP with an unreachable address	Outbound firewall rules and the SDP received
Nobody hears anybody	Codec, SRTP, media inactive or rejected with port 0	Offer and answer side by side
Audio stops after a hold or transfer	A new SDP in a re-INVITE, direct media between the endpoints	direct_media and the re-INVITE’s SDP
Audio stops after a few minutes of silence	Short UDP session timeout on the firewall	UDP session timeouts and keepalive messages
The call drops at around 32 seconds	ACK lost because of a Contact with a private address	The Contact header of the 200 OK
Fails on some calls and not others	RTP range half forwarded, two outbound links	The RTP port of the calls that failed
Silence only before the answer	Early media blocked	The 183 with SDP and what the PBX does with it

Why does the call drop after 32 seconds?

Because the ACK never arrived. Under RFC 3261, the side that answers a call retransmits the 200 OK until it receives the ACK. If 64 × T1 passes without an ACK, the session must be torn down. With the default T1 of 500 ms, that is 64 × 0.5 = 32 seconds. The ACK is sent to the address in the 200 OK’s Contact header; if the PBX behind NAT put its private address there, the ACK gets lost, the PBX keeps retransmitting and drops the call when the timer runs out. It isn’t an audio problem, but it shows up alongside one, because it comes from the same mishandled NAT.

How do I fix silent calls on Asterisk, Issabel and FreePBX?

On Asterisk, Issabel and FreePBX, fixing silent calls comes down to four adjustments: set the external address and the local networks on the transport, turn off direct media and turn on symmetric RTP on the trunk endpoints, align the rtp.conf RTP range with the firewall, and check the codecs and media encryption on both sides.

PJSIP: the transport

In PJSIP, the external address and the local networks live on the transport. Using documentation addresses, with 203.0.113.10 as the public IP and two internal networks:

[transport-udp-nat]
type=transport
protocol=udp
bind=0.0.0.0:5060
external_media_address=203.0.113.10
external_signaling_address=203.0.113.10
local_net=192.168.1.0/24
local_net=10.20.0.0/16

external_media_address is the address that goes on the SDP’s c= line; external_signaling_address is the one that goes in the SIP headers, such as Contact and Via. local_net lists the networks for which Asterisk keeps the private address. List every internal network, including branch office VPNs.

PJSIP: the trunk endpoint

On the endpoint for the trunk and for remote phones:

[carrier-trunk]
type=endpoint
transport=transport-udp-nat
direct_media=no
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
disallow=all
allow=alaw,ulaw

With direct_media=yes, Asterisk tries to take itself out of the audio path after the answer, with a new INVITE so the two endpoints exchange RTP directly. Across NAT, this tends to fail and the audio vanishes right after the answer or a transfer; direct_media=no keeps the audio flowing through Asterisk. rtp_symmetric=yes turns on symmetric RTP, force_rport=yes replies to the port the message came from, and rewrite_contact=yes stores the address the registration came from, not the one the device claimed. The disallow and allow lines set the accepted codecs, in order of preference; they have to overlap with what the carrier accepts. The command pjsip show endpoint carrier-trunk shows the values in effect.

If the carrier requires SRTP, the endpoint’s media_encryption option has to match it. If it doesn’t use SRTP, the option has to be off.

chan_sip, on older installations

In chan_sip, which recent Asterisk versions no longer ship, the equivalents live in sip.conf: externaddr (formerly externip) for the public address, localnet for the local networks, nat=force_rport,comedia for symmetric RTP and directmedia=no to keep the audio on Asterisk.

rtp.conf: the port range

Asterisk’s RTP port range lives in rtp.conf:

[general]
rtpstart=10000
rtpend=20000

These are the values in Asterisk’s sample file and FreePBX’s default. The firewall’s range has to be exactly the same, or wider. If you need to narrow the range, do the math: each call leg that passes through Asterisk uses a pair of ports (RTP and RTCP), and a call between a phone and the trunk has two legs, so four ports. A range of 10,000 ports holds, roughly, 10,000 ÷ 4 = 2,500 concurrent calls.

In the same file, the strictrtp option, on by default in current versions, makes Asterisk accept RTP only from the source it learned at the start of the call. A carrier that changes the audio source mid-call, for example after a recorded announcement, can have its audio discarded. Turning it off is a diagnostic test, not the permanent fix.

FreePBX and Issabel

In FreePBX, the equivalent fields are under Settings → Asterisk SIP Settings, on the General SIP Settings tab: External Address, Local Networks and RTP Port Ranges. Prefer the interface over the files: FreePBX rewrites the files it generates when it applies the configuration, and manual adjustments go in the files ending in _custom.conf. Issabel ships Asterisk with an interface derived from FreePBX, and the same three items, external address, local networks and RTP range, appear in its SIP settings. On older Issabel systems running chan_sip, the previous section applies.

For a first internal test, FreePBX has an echo test on code *43, and on plain Asterisk the dialplan’s Echo() application does the same. That test only proves the leg between the phone and the PBX; the trunk, the NAT and the firewall are left out.

How do I set up the firewall and router for VoIP audio?

To get VoIP audio through the firewall and the router, three adjustments solve most cases: turn off the SIP ALG when the PBX already handles NAT, forward to the PBX the same UDP RTP range it uses, and give UDP sessions a lifetime longer than the interval between messages.

Turn off the SIP ALG

The name and location vary from vendor to vendor, so always check the documentation for the installed version:

• FortiGate: SIP handling can come from a SIP session helper or from the SIP ALG applied by the VoIP profile on the policies. Check both before concluding that SIP passes through unaltered.
• MikroTik: the helper is under IP → Firewall → Service Ports, in the sip entry. Disable that entry.
• pfSense: the point most often raised for VoIP is outbound NAT changing the source port of connections. An outbound NAT rule with a static port for the PBX’s address prevents the change.
• Broadband routers: many offer the option as “SIP ALG” or “SIP Passthrough” in the advanced NAT settings.

After turning it off, clear the active sessions so the old entries leave the connection table.

Open and forward the RTP range

Forward the entire UDP range, 10000 to 20000 in the example, to the PBX’s internal address, and allow that same range in the inbound rules. For security, restrict the source to the carrier’s addresses whenever it tells you what they are, and do the same for the SIP port.

Adjust the UDP session timeouts

The firewall forgets a UDP mapping that goes without traffic. RFC 4787 requires that timer not to expire in less than 2 minutes and recommends a default of 5 minutes or more. Equipment with shorter timeouts drops the SIP registration’s mapping between two renewals, and the trunk starts receiving calls that never reach the PBX. Two ways out: raise the UDP session timeout on the firewall for the voice ports, or have the PBX send messages more often, with a shorter registration renewal and the AOR’s qualify_frequency in PJSIP, which sends a periodic OPTIONS.

What if there’s an SBC?

An SBC at the edge takes over NAT and anchors the audio between the PBX and the carrier; the PBX talks only to the SBC, on a known network. The thing to watch is not handling NAT twice: an SBC, an ALG and a PBX all correcting the same address produce an inconsistent SDP.

How do I know whether the 0800 or the SIP trunk has silent calls?

The way to know whether an 0800, an IVR or a SIP trunk has silent calls is to call from outside and check the audio in both directions, on a real call, repeatedly. A PBX dashboard can’t see the problem: the trunk shows as registered, the call is answered, and only the person on the line notices the silence.

The test that proves both directions is a call to an echo or tone service. Whatever the call sends has to come back: if the echo returns the audio, it got there and came back. An internal call, an echo test on the PBX itself or the ringback before the answer don’t prove this, because they leave out the trunk, the NAT or the audio path itself after the answer. Because of intermittent faults, such as a half-forwarded RTP range, a single test isn’t enough either: the fault may show up on only some of the calls.

That is what Monitor does for each voice circuit, meaning each monitored SIP trunk, 0800 or support number. 2N5 places real test calls from its own platform, at the agreed pace, with nothing installed on the PBX and no integration with it. When the number is answered by a test tone or an echo service, the call passes when it is answered and the tones it sends come back. Audio in only one direction, or none at all, counts as a failure even when the call connects. See what each call checks in SIP trunk monitoring.

A failure is retried before any alert. At the default pace, each circuit gets a call every 15 minutes; after a failure, the call is repeated three times, every 2 minutes, four failures in a row open an incident and two good calls in a row confirm recovery. The incident alerts the escalation ladder by email and SMS, until someone takes ownership; see alerts and escalation. If the problem is on 2N5’s side, the test is marked monitoring blind and does not count against the circuit.

How do the RTP counters show which side the audio stopped on?

The sent and received RTP counters show which side the audio stopped on because each direction has its own stream. On a normal call, both counters climb together. When one of them sits at zero while the other climbs, one-way audio is proven, and the stalled direction tells you which leg to investigate.

The reference math is simple. With audio packetized every 20 ms, each direction sends 1,000 ÷ 20 = 50 packets per second. A 60-second call has about 3,000 packets in each direction. A received counter at zero next to 3,000 sent leaves no doubt.

In Asterisk, three commands give you that view:

• pjsip show channelstats shows, for each active channel, packets received and transmitted, loss, jitter and round-trip time;
• rtp set debug on shows each packet with its source and destination address, and immediately reveals audio being sent to a private address; rtp set debug ip filters by address;
• on chan_sip, sip show channelstats does the job of the first one.

Outside Asterisk, a packet capture on the PBX or the firewall, opened in Wireshark under Telephony → RTP → RTP Streams, lists each stream with source, destination and packet count. Capturing on both sides of the firewall shows whether the packet stops at the edge. RTCP helps too: under RFC 3550, the sender report carries the count of packets and bytes sent, and the receiver report carries the fraction lost, the cumulative number lost and the jitter. An endpoint that never receives RTCP from the other has the same problem on the return path.

Sent by the PBX	Received by the PBX	Reading
Normal	Zero	Audio from outside isn’t arriving: private IP in the SDP, SIP ALG or inbound RTP range closed
Zero	Normal	The PBX isn’t sending: recvonly or inactive media, codec transcoding failure, direct media
Normal	Normal, but still silent	Audio arrives and isn’t used: SRTP without a key, wrong codec, the leg between PBX and phone
Zero	Zero	No stream at all: media rejected with port 0, inactive, channel not bridged
Climb, then stop	Climb, then stop	A new SDP in a re-INVITE, UDP session timeout expired, source change with strictrtp

What should I take to the carrier?

Take the carrier the time of each failed call, the number called, the Call-ID, the SIP capture with the SDP of the offer and the answer, and the RTP counters for both directions. If your PBX sends audio to the announced address and nothing comes back, the problem is on the carrier’s side or between the two of you.

A silent call has no error code: the call completed with a 200 OK. In Monitor, each incident carries the circuit, the carrier, the first symptom, the SIP code and Q.850 cause of each call, and the last healthy call, in a block ready to paste into the ticket. The SIP code lookup helps read the codes of calls that were rejected along the way.

Checklist

1. Confirm which direction fails and on which calls: all of them, only inbound, only some.
2. Capture the SIP and read the SDP: is the address on the c= line the public one?
3. Turn off the SIP ALG on the router or firewall, and reset the active sessions.
4. Set external_media_address, external_signaling_address and every network in local_net.
5. Use direct_media=no, rtp_symmetric=yes, force_rport=yes and rewrite_contact=yes on the trunk and remote phones.
6. Align the rtp.conf range with the firewall’s UDP forwarding, all of it.
7. Adjust the UDP session timeouts or shorten the registration renewal.
8. Compare the codecs and encryption of the offer and the answer.
9. Check what happens to the 183 and the early media.
10. Prove the result with real calls from outside to an echo or tone, repeatedly, watching the RTP counters for both directions.

Frequently asked questions

Why does a VoIP call connect and then stay silent?

Because SIP, which sets up the call, and RTP, which carries the audio, take different paths. The 200 OK proves SIP got through. The audio depends on the address and port announced in the SDP; if that address is private, the port is closed on the firewall or the two sides don't agree on a codec or encryption, the call is silent.

What is one-way audio?

It is a call in which one side hears and the other doesn't. The direction that fails tells you where to look: when the person inside can't hear the person outside, inbound audio isn't arriving, almost always because of a private IP in the SDP, a SIP ALG or an RTP range that isn't forwarded. When it's the other way round, look at the PBX's outbound side and the far end's SDP.

Does turning off the SIP ALG always fix it?

Not always, but it is the recommended first step when the PBX already handles NAT. The SIP ALG rewrites addresses inside SIP and the SDP, and the double correction produces mismatched addresses. After turning it off, the PBX has to announce the right external address and the RTP range has to be forwarded, or the problem stays.

Why does the call drop after about 30 seconds?

Almost always because the ACK never arrived. Under RFC 3261, the answering side retransmits the 200 OK until it receives the ACK and, after 64 × T1, 32 seconds with T1 at 500 ms, tears down the session. The ACK goes to the address in the Contact header; if that address is private, it gets lost in the NAT.

How do I test whether audio flows in both directions?

With a real call, coming in from outside through the trunk, to an echo or tone service: whatever goes out has to come back. An internal call only proves the leg between the phone and the PBX. Meanwhile, the PBX's RTP counters show whether packets are leaving and arriving in both directions.

Sources

1. RFC 3261: SIP, including retransmission of the 200 OK until the ACK (64 × T1)
2. RFC 3264: the offer/answer model with SDP
3. RFC 3550: RTP and RTCP, packet counters and jitter
4. RFC 3960: early media and ringing tone generation in SIP
5. RFC 6314: NAT traversal practices for SIP applications
6. RFC 4787: NAT behavior for UDP, including mapping timeouts
7. RFC 8489: STUN

Keep reading

• Voice circuit monitoring: the complete guide
• SIP trunk monitoring
• Voice quality: MOS, MOS-LQO and ViSQOL in practice
• SIP code lookup
• Alerts and escalation