No audio / one-way audio
The call shows as connected — ANSWERED, both sides picked up — but there's silence, or only one side can hear the other. This is almost always the audio path (RTP), not the signalling that set the call up, which is why A call fails won't show it as a failure at all.
The product's own pages give you the settings that most often cause this and one technical capture to hand to whoever has deeper (network-level) access. They are not a full audio diagnostic tool — for a genuinely puzzling case, the SIP/RTP capture below is what a technical colleague or support would want to see next.
1. NAT on the device
By far the most common cause. A phone behind a router (almost every office or home connection) needs its device configured with the right NAT setting, or the audio stream can be sent to the wrong address even though registration and call setup both succeed.
This is the same field covered in A phone does not register and in full in Device settings in depth — for one-way or no audio, check it even if registration itself looks fine, since a wrong NAT setting doesn't necessarily stop a phone from registering.
2. What the call's technical panel shows
A connected call's detail page has a SIPCHANINFO panel with the addresses the call actually used — useful for spotting a mismatch between where a device thinks it is and where the system saw it calling from.
| Field | Meaning |
|---|---|
Peer-IP | The address the far end (device or provider) claimed as its own. |
Recv-IP | The address the traffic actually arrived from. Behind NAT, this is the router's public address — if it differs a lot from what's expected, that's worth a closer look. |
User-Agent | Which phone or app software placed or received the call. |
T.38 Passthrough | Whether fax-over-IP passthrough applied to this call — relevant only if the "call" was actually a fax. |
3. The SIP/RTP capture (technical)
The same page has a PCAP / SIP ladder panel — a recorded capture of the signalling messages for that call, shown as a diagram and as a message table, plus a separate Call log panel that can pull the matching trace from the Asterisk log. New calls are captured automatically; for one already a little old, the Capture button pulls it from a short-lived rotating store (a couple of days) if it's still there.
Reading this capture in depth is a technical, network-level task — but knowing it exists is often enough: it's the one thing worth mentioning when you hand a "no audio" case to your provider or a technical colleague, since it can show exactly what was negotiated and where the packets went.
Check
Confirm NAT and Transport are correct for how this specific phone connects, then place a test call. If the setting was right and audio still fails only for calls through one particular provider, the issue more likely sits with that provider — see A provider is down.