A call where you only hear on one side: the five causes

A call connects, the conversation starts, and one of the two parties hears nothing. It's confusing because everything seems to work: the phone rang, the call was answered, the duration counter is running. And that is precisely what points to the cause.

Signaling and audio do not take the same path

In IP telephony, two streams coexist. Signaling carries the call setup, and it goes through the server. Audio travels separately, often directly between the devices. When the call connects but the sound is missing, signaling is fine: the problem is on the audio path.

1. A private address announced to the outside

The phone announces the address where it wants to receive audio. If it announces its local address, something like 192.168.x.x, while the other party is on the internet, the sound goes to an address that doesn't exist on the other side. This is the most common cause, and it almost always comes from a device with faulty NAT traversal.

2. A firewall that doesn't open the return path

Audio goes out, but the response doesn't come back in. Many firewalls allow the outbound stream and block the inbound one, even though it's the same exchange. The symptom is asymmetric: the caller hears, the person who answered doesn't, or the other way round.

3. A device that rewrites the signaling

Some routers include a feature that claims to fix up telephony traffic by rewriting messages in transit. It's often enabled by default, and it causes more faults than it solves: it changes the announced addresses without keeping them consistent with the rest.

4. A transferred or resumed call

A transfer, a hold, or a retrieve renegotiates the audio path mid-call. If a device doesn't follow that renegotiation, the sound is lost exactly at the moment of the transfer, even though the initial call was perfect. The fault is then reproducible: always at the same action.

5. One direction filtered by the carrier

Rarer, but real: the break is at a carrier, on a specific route. You identify it by comparing several calls to the same destination and checking whether the fault follows the route rather than the equipment.

How we settle it, without guessing

The method that works is to look at the packet counters for both directions during the call, not the summary at the end of the call. If one direction shows packets and the other shows zero, you immediately know which side to look at. We monitor this continuously, which often lets us spot the fault before the customer calls.

• Only one handset affected: look at the device or its local network
• A whole site affected: look at the firewall or the router
• Only one destination affected: look at the route
• Only after a transfer: look at the renegotiation

The special case of the softphone

Software installed on a computer adds a layer: the operating system, its local firewall, and sometimes a corporate VPN. The same user can perfectly well hear correctly on their desk phone and not on their computer, with the same account. In that case, the problem is neither the account nor the platform: it's the workstation or the tunnel it uses.

The useful reflex is to turn off the VPN for the length of a test call. If the sound comes back, you know where to look, and you avoid hours of investigation on the phone system.

The two counters that give the answer

For each call, two counters exist: audio packets sent and packets received, on each side. A healthy call shows all four counters increasing together. One-way audio shows three counters rising and one stuck at zero, and that zero points precisely to the side to examine.

Two false alarms to rule out before concluding anything: a call on hold deliberately stops exchanging audio in one direction, and a call that's still ringing has no established stream yet even though the ringback tone is already playing. Without these two filters, you'd think there was a fault every hour.

What to remember

• Signaling works, so look at the audio path
• Only one handset affected: the device or its local network
• A whole site affected: the firewall or the router
• Always at the same point in the call: a renegotiation or a timeout

We monitor these counters continuously, which often lets us detect the fault before the customer calls. This is described on our infrastructure and monitoring page.