No audio, one-way audio, echo, “robot” voice

A phone can be registered, place calls and pick them up — and still carry no sound at all. The reason is that registration and voice are two different roads: registration travels as signalling messages to port 5060, while the voice is a separate stream of packets on ports 10000–20000. The venue’s router can let the first through and cut the second. This is neither a phone fault nor a PBX fault: nine times out of ten the network between them is in the way, and you can find the culprit in a few minutes.

General phone setup is in the overview “SIP Phone Setup”, other symptoms — in troubleshooting by symptom.

Check the admin panel first#

1. The *43 echo test from the very same device. The PBX answers, plays a beep after a second and then plays your voice back. The beep comes before the echo on purpose — it tests the “PBX → phone” direction separately from the microphone:

   What you hear	What it means
   A beep, then your own voice	Audio flows both ways — the network up to the PBX is fine
   A beep, but no voice	Audio does not get from the phone to the PBX
   Not even a beep	Audio does not get from the PBX to the phone
   You hear yourself, but choppy or late	The road exists but is poor: packet loss, jitter, an overloaded link

   Talk into *43 for about ten seconds — then the PBX has time to measure loss, jitter and delay. The full walkthrough — “Checking call quality”.

2. The call log — open the problem call. The “Audio” line of an answered call tells whether voice flowed both ways: “both ways”, “no audio came from the phone of ext. 101” or “no audio came from the other party” — next to it, loss, jitter and RTT for each side.

3. Device card → “Audio both ways” — how many of this phone’s calls were one-way. For models that lose their voice at the moment of answer, the PBX turns on “ringback from the PBX” by itself — that is shown here too.

4. The call recording, if recording is on: whoever can be heard on the recording, their voice reached the PBX.

5. The SIP trace on a dedicated PBX: the audio description (SDP, the c= and m=audio lines) shows which address and port each side announced.

Why the phone is registered but there is no audio#

Our PBX always carries the voice through itself (phones never exchange audio directly) and sends voice back to wherever the phone’s voice came from, not to the address the phone claims for itself. That is why a phone behind a router needs neither STUN nor port forwarding. But it also follows that if nothing gets from the phone to the PBX, the PBX has nowhere to answer — the result is silence in both directions.

What most often breaks the voice while registration is fine:

1. SIP ALG on the router (“SIP Helper”, “SIP Passthrough”). The router “helps” SIP by rewriting the addresses inside signalling messages — often wrongly. Registration goes through, the audio does not, or only one way. Where to turn it off on popular routers — “Network, router and internet”.
2. Outbound UDP 10000–20000 is blocked. The firewall lets through “the internet” (web ports) and 5060, but not the voice ports.
3. Double NAT — the provider’s router plus your own behind it: addresses are rewritten twice, and one of the rewriters gets it wrong.
4. Wi-Fi — a guest network with client isolation, a weak signal, the phone far from the access point.
5. An overloaded link — CCTV uploading recordings to the cloud, guests watching video on the same internet: the voice arrives full of holes.

No audio at all#

Why it happens#

• The voice ports are closed in both directions: the firewall or router blocks outbound UDP 10000–20000. Since nothing came from the phone, the PBX does not know where to send its answer.
• SIP ALG rewrote the audio address in the call description, and the packets go the wrong way.
• Voice encryption (SRTP) is on in the phone — our PBX does not offer it by default.
• All three of our codecs (G.711 PCMA, PCMU and G.722) are disabled in the phone. Then the call usually does not even connect — the answer is 488.
• The phone connects through a VPN or corporate proxy that does not pass UDP.

What to do#

After each step, dial *43; go further only if it did not help.

1. Turn off SIP ALG on the router and reboot the router and the phone.
2. Open outbound UDP 10000–20000 to the PBX address (10000–10200 is enough for the shared server).
3. In the phone, turn off SRTP / voice encryption and make sure at least G.711 (PCMA or PCMU) is enabled.
4. Plug the phone by cable into the venue’s main network, bypassing guest Wi-Fi and VPN.
5. If your own router sits behind the provider’s router, switch the provider’s router to bridge mode or plug the phone straight into it. More in “Network, router and internet”.

Only one side can be heard#

Why it happens#

One-way audio has two different cases — *43 tells them apart by the beep:

• “They cannot hear me” (a beep, but no own voice): audio does not get from the phone to the PBX. Causes: SIP ALG, a muted microphone or Mute key, a faulty headset, headset mode on with no headset plugged in, the phone on guest Wi-Fi. Some models lose their voice exactly at the moment of answer — the phone changes its audio port (the D-Link DPH-150S behaves this way, for example); for known models the PBX fixes this itself by turning on “ringback from the PBX”.
• “I cannot hear them” (no beep): audio does not get from the PBX to the phone: a strict firewall, SIP ALG, double NAT. If the call log says “no audio came from the other party”, it was the carrier’s or caller’s side that stayed silent — your phone has nothing to do with it.

What to do#

1. Dial *43 and find the direction by the beep.
2. “They cannot hear me”: check Mute and the headset, try the handset instead of speakerphone; turn off SIP ALG; take the phone off guest Wi-Fi.
3. “I cannot hear them”: turn off SIP ALG; check the firewall (outbound UDP 10000–20000 and the replies to it); remove the double NAT.
4. *43 is clean both ways, but one-way audio happens only on external calls — the fault is between the PBX and the carrier. Compare with an internal call to a colleague and send the call time to support.
5. One-way audio at the moment of answer and only on one model — on a dedicated PBX, turn on “Ringback from the PBX on outgoing calls” in the extension’s “Phone settings”. The price: the carrier’s announcements before the answer (“the subscriber is unavailable”) will not be heard by the employee.

Echo#

Why it happens#

The main rule of echo: the person who hears it is the one whose voice is reflected at the other end. If you hear your own echo, the source is at the other party: their speakerphone, a cheap headset, a turned-up speaker, a phone in a car — the microphone picks up your voice from their speaker and sends it back. If a guest complains, the source is on your side.

The second common source is an analogue line: an ordinary telephone through a gateway adapter (ATA), or a landline through a gateway. At the junction of the “four wires” of digital and the “two wires” of analogue, part of the signal is reflected back; the gateway’s echo canceller suppresses it.

The longer the delay on the line, the more noticeable the echo: a reflection that arrives almost at once blends in, one that arrives late is heard as a repeat.

In *43 you are supposed to hear yourself — that is the test itself, not an echo problem. But if your voice comes back noticeably late in *43 (RTT in the log above 300 ms), any echo on real calls will be more irritating: the link is to blame.

What to do#

1. Work out who hears the echo. You — look at the other party; the guest — look at yourself.
2. Echo from your device: the handset instead of speakerphone, a lower speaker volume, another headset; do not put the phone against a wall or glass if you talk on speaker. According to Yealink’s documentation, a sensitive microphone placed too close also causes echo.
3. Echo on calls through a gateway (an analogue phone or a landline): make sure the gateway’s echo canceller is on — on Grandstream HT this is the Disable Line Echo Canceller (LEC) field, which must be No for voice (the factory value); return the port gain (Rx / Tx gain) to factory values if it was raised.
4. Echo on all external calls through one carrier, with clean internal calls — send the call times to support.

“Robot” voice, gurgling, missing syllables#

Why it happens#

The voice is cut into small packets, and each lost packet is a lost piece of a syllable. Packets that arrive unevenly are smoothed out by the phone for a while, but if the spread is large, the sound breaks up. Hence the three numbers the PBX measures in *43 and on every answered call:

The same thresholds give the “quality good / acceptable / poor” ratings in the log.

Where loss and jitter come from: Wi-Fi (especially far from the access point or on a crowded channel), an overloaded internet link (cameras, uploads, updates, guest Wi-Fi on the same line), a weak router that cannot cope with the load, mobile internet and VPN.

What to do#

1. Run *43 twice: at a quiet time and at peak hour. Good when quiet and poor at peak — the link is saturated; poor always — the network or Wi-Fi.
2. Connect the phone by cable instead of Wi-Fi.
3. Separate guest Wi-Fi from the staff network and cap its speed; move camera video uploads to the night.
4. Turn on priority for phones (QoS) on the router if it supports it. How much bandwidth a call needs — “Network, router and internet”.
5. Did not help — show the provider the numbers from the log (loss, jitter, time): that makes it a conversation about facts, not “we can’t hear you well”.

How to tell whose side the fault is on#

What to send to support#

• the date and time of the call to the minute, the other party’s number and the extension;
• who could not hear whom, or who heard the echo;
• the *43 result from this device: beep, your own voice, choppy — and the numbers from the log (loss, jitter, RTT);
• a screenshot of the call card from the log with the “Audio” line;
• the phone’s model and firmware (the string from the equipment tag), how it is connected (cable / Wi-Fi), the router model and whether SIP ALG is off;
• on a dedicated PBX — the SIP trace text of a repeated call.

How to reach us — “Support”.

Frequently asked questions#

In *43 I hear myself with a delay — is that echo?#

No. *43 is exactly “play your voice back”: the delay equals the trip to the PBX and back. Under 300 ms it is barely noticeable. If the lag is audible (half a second or more), real calls will be uncomfortable — the link is to blame, not the phone.

Audio drops out only on calls from mobiles — is it on our side?#

Most likely not: a mobile caller has their own weak stretch — the cellular network. Run *43 from your device: if it is clean and internal calls are too, send the times of a few such calls to support — we will look at where the audio is being lost.

Would other codecs help — G.729 or Opus?#

No. Our PBX offers phones G.711 (PCMA, PCMU) and G.722 — every phone supports them, and they do not compress the voice, so they cope better with errors. G.729, Opus and AMR are not offered to phones: there is no point enabling them in the phone.

Can I turn on voice encryption so the router “keeps out” of the call?#

Not at the moment: phones work over UDP / TCP without TLS and SRTP. SRTP switched on “just in case” in the phone is exactly what gives silence. What helps against the router is not encryption but SIP ALG switched off.

Related sections#

• Phone not working: troubleshooting by symptom
• SIP Phone Setup — checking call quality with *43, venue network
• Network, router and internet for telephony — SIP ALG by router brand, double NAT, bandwidth
• Calls drop — a drop after 30 seconds also starts with SIP ALG
• Call log and SIP trace
• Gateways for analogue phones: Grandstream HT, Yeastar TA and Dinstar DAG

Sources#

• RFC 3550 — RTP and the RTCP reports from which loss, jitter and delay are calculated — https://www.rfc-editor.org/rfc/rfc3550
• ITU-T G.114 — recommendations on one-way delay (the 150 / 300 ms round-trip thresholds in *43 are industry practice) — https://www.itu.int/rec/T-REC-G.114
• Yealink SIP-T2/T3/T4/T5/CP920 Administrator Guide V86.60 — Troubleshooting → Audio Issues: causes of echo and intermittent voice
• Grandstream HT80x Administration Guide — Disable Line Echo Canceller (LEC), Rx / Tx gain — https://documentation.grandstream.com/knowledge-base/ht80x-administration-guide/
• PBX code: shared/sip/advanced-options.json (direct_media=no, rtp_symmetric, force_rport, rewrite_contact, codecs, rtp_timeout=0), sip-edge/asterisk/rtp.conf (strictrtp=yes, ports), sip-edge/sipsync/linecheck.go (the *43 echo test, thresholds 1 / 3 %, 30 / 50 ms, 150 / 300 ms)
• Admin panel screens: the call log “Audio” line (admin/app/[locale]/calls/i18n/CallsPbxLog.i18n.ts), the “Audio both ways” block (admin/components/integrations/SipDeviceMediaHealth.tsx), “Ringback from the PBX on outgoing calls” (admin/components/integrations/SipOptions.i18n.ts)