Calls ring and connect but go silent right at answer — is that different?

Slightly: silence from the first moment after 200 OK/ACK usually means the media path defined in that very SDP exchange is wrong or blocked. If calls have audio and then drop to silence mid-call, suspect session timers, NAT timeouts or a path change instead — see the timed-drops guide.

Could this be a provider outage with no announcement?

Yes — media relays fail independently of signaling, and status pages lag. Your capture evidence (RTP sent correctly, none returned, across multiple calls) is what turns a vague report into their priority ticket.

The problem is only on one phone. Network or phone?

Almost certainly the phone or its port: swap the phone with a working one at the same jack. Fault follows the phone → replace/reset it. Fault stays at the jack → switch port, cable, or that drop's VLAN/ACL.

Troubleshooting · Symptoms

No Audio at All: When Calls Connect in Silence

By the VoIP Cost Guide Editorial Team | Last updated: October 2026

The phone rings, the other side answers, the call timer runs — and both parties hear nothing at all. Total silence on an established call feels alarming, but it is usually simpler than one-way audio: with both directions dead, suspect a media path that was never established, rather than one direction's addressing quirk.

The discipline is the same: signaling (SIP) clearly worked, so leave it alone. This is an RTP problem, and a capture will show you exactly where the media dies.

The five places media dies

RTP blocked both ways. A firewall policy permits SIP but no UDP media range at all — classic after a firewall replacement or a 'tighten everything' change. Calls set up perfectly; zero RTP crosses.
SDP advertises an unreachable address. The c= line carries a private or stale public IP (multi-WAN, changed ISP), so both ends send voice to addresses that go nowhere.
The media gateway/SBC is down or misrouted. Signaling and media often take different paths; a media relay failure silences every call while registrations and ringing look healthy.
Codec negotiation produced silence. Rare but real: endpoints 'agree' in SDP but a transcoding fault or a telephone-event mismatch yields a stream of silence packets — the capture shows RTP flowing, full of nothing.
The endpoints themselves. A muted handset, a headset plugged into the wrong jack, a softphone using a dead audio device — check the embarrassingly simple first on single-phone reports.

What the capture tells you in 60 seconds

Filter the capture for RTP. Four outcomes localize the fault immediately: no RTP anywhere — media was never sent; check SDP negotiation and the sending endpoint. RTP leaves your network, nothing returns — addressing or upstream media failure; compare SDP addresses to reality. RTP flows both ways at the edge but not at the phone — internal firewall/VLAN/ACL problem. RTP flows everywhere and calls are still silent — inspect payload: silence packets (check the audio levels in Wireshark's RTP player) point at endpoints or a transcoder, not the network.

# Quick triage in Wireshark
Telephony > RTP > RTP Streams
  Look for: streams in BOTH directions, similar packet counts
  One stream missing entirely  -> media never established
  Both present, one near zero  -> see the one-way audio guide
  Both healthy, still silent   -> play the stream: is it carrying silence?

Diagnosis sequence

Reproduce with a test call and note: all calls or one phone? Internal calls (extension to extension) affected? That single split divides LAN faults from provider/WAN faults.
Capture at the network edge for one failing call. Classify with the four outcomes above before changing anything.
If no RTP leaves: read the SDP in the INVITE and 200 OK. Confirm the media address is your real public IP and the port is inside the provider's documented RTP range; confirm your firewall permits that UDP range outbound and the return traffic.
If RTP leaves and nothing returns with correct SDP addressing, the fault is upstream — send the provider the capture and the call example with timestamps.
If RTP is healthy everywhere, test with a known-good handset/headset and check the negotiated codec on both ends; reset the affected phone's audio settings or replace it.
Verify the fix by repeating the original failing call type and confirming two symmetric RTP streams with real audio energy.

Frequently asked questions

Calls ring and connect but go silent right at answer — is that different?: Slightly: silence from the first moment after 200 OK/ACK usually means the media path defined in that very SDP exchange is wrong or blocked. If calls have audio and then drop to silence mid-call, suspect session timers, NAT timeouts or a path change instead — see the timed-drops guide.
Could this be a provider outage with no announcement?: Yes — media relays fail independently of signaling, and status pages lag. Your capture evidence (RTP sent correctly, none returned, across multiple calls) is what turns a vague report into their priority ticket.
The problem is only on one phone. Network or phone?: Almost certainly the phone or its port: swap the phone with a working one at the same jack. Fault follows the phone → replace/reset it. Fault stays at the jack → switch port, cable, or that drop's VLAN/ACL.

Sources and further reading

Related guides

Disclaimer: This guide is educational information based on published VoIP standards and professional practice, not engineering advice for your specific system. VoIP pricing, taxes and fees change and vary by provider and location — verify current figures with providers before purchasing. If your phone system supports emergency calling, work with your provider or a qualified VoIP engineer for changes that affect E911.