How to Troubleshoot No Audio in a SIP Call

A call that connects with no audio in either direction is a different problem from one-way audio. One-way audio is almost always NAT. Total silence more often starts on the device itself: a denied microphone permission, the wrong output device, a muted call, or a Bluetooth headset that took the audio route and is sitting in a drawer. Once the device is ruled out, the remaining causes are a codec the two sides do not share, an encryption setting the server cannot honour, and a firewall that blocks RTP in both directions.

Quick checklist

1. Check the microphone permission for the app on macOS (System Settings > Privacy & Security > Microphone) or iOS (Settings > Privacy & Security > Microphone).
2. Check the selected input and output devices, and whether the call is muted.
3. Disconnect Bluetooth headsets and test with the built-in speaker and microphone.
4. Set Encrypt audio to Optional if the server might not support SRTP.
5. Make sure the server allows G.711 ulaw or alaw, which almost every SIP device supports.
6. Confirm the RTP port range is open on the server's firewall.
7. Test from another network to separate device problems from network problems.

Is the device allowed to use the microphone?

On Apple platforms an app cannot capture audio until the user grants microphone access. If the prompt was declined, or the permission was later removed, the app sends silence and the far end hears nothing. Because many softphones also play received audio through the same audio session, a failed session can mute the output too.

• macOS: System Settings > Privacy & Security > Microphone. Turn the switch on for the softphone, then restart the app.
• iOS and iPadOS: Settings > Privacy & Security > Microphone, or Settings > the app's own entry.

If the PBX is on the local network, the Local Network permission matters as well. Apple's technote TN3179 explains that without it the app cannot send to private addresses, which blocks RTP to the PBX even when SIP signalling went through a different path.

Are the right audio devices selected?

Softphones on the Mac let you pick an input, an output and a ringer device separately. A USB headset that was unplugged, a display with built-in speakers, or a virtual audio device left over from a meeting app can all be selected without you noticing. In SIPdia the selectors are in the app's settings on the Mac, per its documentation. Choose the built-in microphone and speakers as a test. If audio returns, the problem was the device selection, not the network.

Also check that another app is not holding the microphone exclusively, and that the system input volume is not at zero.

Is the call muted or on hold?

Obvious but common. A muted call sends silence, and some PBXs stop sending audio to a phone that stops sending, which makes the silence mutual. Hold does the same on purpose. Check the mute and hold state in the call window, and the mute switch on any headset.

Did a Bluetooth device capture the audio?

On iPhone, iPad and Mac, a paired headset or car system can become the active audio route automatically. If that device is out of range, switched off or in a bag, both input and output vanish. On iOS use the audio route button in the call screen to pick the speaker or earpiece. On the Mac, disconnect the Bluetooth device or choose a different output in the app. CarPlay and some car kits also take the route when the phone connects, which explains silent calls that start as you get into the car.

Do the two sides share a codec?

Every SIP device lists its codecs in the SDP; the server picks one both sides support. SIPdia offers Opus, G.711 ulaw and G.711 alaw according to its documentation, and does not offer G.722 or G.729. If the extension on the PBX allows only codecs the phone lacks, the normal result is a 488 Not Acceptable Here reply (RFC 3261 section 21.4.26) and the call fails. Some servers, however, accept the call and then send a codec the phone did not agree to, or transcode badly, and the result is a connected call with silence.

Enable ulaw or alaw on the extension and on the trunk. G.711 is the most widely supported codec, so allowing it usually removes codec negotiation from the list of suspects. SIP codecs explained describes the trade-offs.

Does the encryption setting match the server?

SRTP (RFC 3711) encrypts the RTP stream, and both ends must agree to use it. In SIPdia the Encrypt audio option has three states, per the app's documentation:

• Off sends plain RTP.
• Optional offers SRTP and falls back to plain RTP if the server declines.
• Required offers only SRTP.

If Required is set and the server does not support SRTP, the server may answer 488, or some servers answer the plain-RTP part of the offer and the phone discards the unencrypted packets. Either way there is no audio. Set the option to Optional and test. If audio returns, the server lacks SRTP and the administrator must enable it before Required can be used. The reverse mismatch also exists: a server configured to require encryption rejects a phone set to Off. TLS and SRTP explains how signalling and media encryption fit together.

Is RTP blocked in both directions?

SIP and RTP travel on different ports. A firewall that allows the SIP port but nothing else lets the call set up and then drops every voice packet. On Asterisk-based systems the default RTP range is UDP 10000 to 20000; other servers and providers document their own. The rule must allow UDP in that range between the phones and the server. If both the phone and the server are behind separate NATs, the server also needs its external address configured and the RTP range forwarded, as described in How to Fix One-Way Audio in VoIP Calls.

A quick test: call from mobile data instead of Wi-Fi. If audio works there, the Wi-Fi network's firewall or router is dropping RTP.

How do I confirm whether RTP is flowing?

Detailed logs in the softphone show the SDP in the INVITE and the 200 OK: the IP address, port and codec each side proposed. Compare them. If the server's SDP names a private address and you are outside the office, the server needs its external address set. On the server side, Asterisk can show RTP statistics and packet counts per channel; the Asterisk documentation describes the commands. Zero packets received on the server means your outbound RTP is blocked; packets received but none sent means a server-side codec or encryption problem.

Next steps

If sound returns in one direction but not the other after these checks, continue with How to Fix One-Way Audio in VoIP Calls. To choose audio devices and permissions correctly from the start on a Mac, follow the macOS setup tutorial. For the codec negotiation background, read SIP codecs explained.