When an agent can't hear the customer but the customer hears them

The agent says the customer can hear them perfectly, but the agent hears nothing back. The call connected, both parties are on the line, and yet audio only travels one way. This classic symptom has a precise name and a narrow set of causes, which is good news: once you recognise it, you are not guessing across the whole system, you are looking at one direction of one stream.

What one-way audio actually is

One-way audio means the call's RTP media is flowing in only one direction. RTP is the stream of voice packets that carries each side of the conversation, and the two directions are independent — packets from the agent to the customer travel on a different path than packets from the customer back to the agent. If the customer hears the agent but the agent hears silence, then the customer-to-agent stream is being dropped somewhere along its return path, while the outbound stream is fine.

Why one direction goes missing

The call itself is set up over SIP (Session Initiation Protocol), the signalling protocol that negotiates where each side should send its audio. The trouble is that signalling and media take different paths, and the addresses exchanged during setup can be wrong. The usual culprit is NAT traversal: when the agent's device sits behind a router doing network address translation, it advertises a private address that the dialer cannot reach. The dialer dutifully sends return audio to that unreachable address, and it goes nowhere. A firewall that allows the signalling ports but blocks the media ports produces the same one-sided result.

Finding which side is broken

Each leg of the call is a Channel on the box, and you can confirm media flow per channel. A SIP trace captures the SIP exchange so you can see the actual IP addresses and ports each side offered for audio — if the agent's device advertised a private address, it will be right there in the trace. From there you compare the address the dialer is sending return audio to against an address it can actually reach.

Following the broken leg

sequenceDiagram
  participant C as Customer
  participant D as Dialer
  participant A as Agent
  C->>D: Customer audio RTP
  D->>A: Forward customer audio
  Note over D,A: This leg is blocked
  A->>D: Agent audio RTP
  D->>C: Forward agent audio
  Note over C: Customer hears agent fine

The diagram shows the asymmetry plainly: the agent-to-customer stream completes, so the customer hears the agent, while the customer-to-agent stream is blocked on the agent's leg, so the agent hears silence. Whatever sits between the dialer and the agent device — the agent's router, a firewall rule, or a misadvertised address from NAT traversal — is dropping that one direction. A Softphone or browser Webphone behind a home router is the most common place this shows up.

Where to go next

For the step-by-step fix once you have confirmed the direction, see fixing one-way audio on VICIdial calls. For the broader first-response checklist, see the VICIdial troubleshooting playbook.

If you would rather not chase NAT and firewall rules every time an agent connects from a new network, VICIfast runs a hardened, managed VICIdial box that is live in under 40 seconds. See our plans and pricing.