Solved Incoming calls with no audio

Status
Not open for further replies.

yogasensai

Free User
Joined
Feb 16, 2023
Messages
21
Reaction score
3
Hello we are getting occasional incoming calls with no audio. Some days it doesn't happen and other days its more frequent. What do I need to check to fix this?



Firewall test results:



resolving 'stun-au.3cx.com'... done
resolving 'stun2.3cx.com'... done
resolving 'stun3.3cx.com'... done
resolving 'sip-alg-detector.3cx.com'... done
testing 3CX PhoneSystem 01 SIP Server... done
stopping service... done
detecting SIP ALG... not detected
testing port 5060... done
starting service... done
testing 3CX PhoneSystem Media Server... done
stopping service... done
testing port 5090... done
testing ports [9000..9398]... done
testing port 9000... done
testing port 9002... done
testing port 9004... done
testing port 9006... done
testing port 9008... done
testing port 9010... done
testing port 9012... done
testing port 9014... done
testing port 9016... done
testing port 9018... done
testing port 9020... done
testing port 9022... done
testing port 9024... done
testing port 9026... done
testing port 9028... done
testing port 9030... done
testing port 9032... done
testing port 9034... done
testing port 9036... done
testing port 9038... done
testing port 9040... done
testing port 9042... done
testing port 9044... done
testing port 9046... done
testing port 9048... done
testing port 9050... done
testing port 9052... done
testing port 9054... done
testing port 9056... done
testing port 9058... done
testing port 9060... done
testing port 9062... done
testing port 9064... done
testing port 9066... done
testing port 9068... done
testing port 9070... done
testing port 9072... done
testing port 9074... done
testing port 9076... done
testing port 9078... done
testing port 9080... done
testing port 9082... done
testing port 9084... done
testing port 9086... done
testing port 9088... done
testing port 9090... done
testing port 9092... done
testing port 9094... done
testing port 9096... done
testing port 9098... done
testing port 9100... done
testing port 9102... done
testing port 9104... done
testing port 9106... done
testing port 9108... done
testing port 9110... done
testing port 9112... done
testing port 9114... done
testing port 9116... done
testing port 9118... done
testing port 9120... done
testing port 9122... done
testing port 9124... done
testing port 9126... done
testing port 9128... done
testing port 9130... done
testing port 9132... done
testing port 9134... done
testing port 9136... done
testing port 9138... done
testing port 9140... done
testing port 9142... done
testing port 9144... done
testing port 9146... done
testing port 9148... done
testing port 9150... done
testing port 9152... done
testing port 9154... done
testing port 9156... done
testing port 9158... done
testing port 9160... done
testing port 9162... done
testing port 9164... done
testing port 9166... done
testing port 9168... done
testing port 9170... done
testing port 9172... done
testing port 9174... done
testing port 9176... done
testing port 9178... done
testing port 9180... done
testing port 9182... done
testing port 9184... done
testing port 9186... done
testing port 9188... done
testing port 9190... done
testing port 9192... done
testing port 9194... done
testing port 9196... done
testing port 9198... done
testing port 9200... done
testing port 9202... done
testing port 9204... done
testing port 9206... done
testing port 9208... done
testing port 9210... done
testing port 9212... done
testing port 9214... done
testing port 9216... done
testing port 9218... done
testing port 9220... done
testing port 9222... done
testing port 9224... done
testing port 9226... done
testing port 9228... done
testing port 9230... done
testing port 9232... done
testing port 9234... done
testing port 9236... done
testing port 9238... done
testing port 9240... done
testing port 9242... done
testing port 9244... done
testing port 9246... done
testing port 9248... done
testing port 9250... done
testing port 9252... done
testing port 9254... done
testing port 9256... done
testing port 9258... done
testing port 9260... done
testing port 9262... done
testing port 9264... done
testing port 9266... done
testing port 9268... done
testing port 9270... done
testing port 9272... done
testing port 9274... done
testing port 9276... done
testing port 9278... done
testing port 9280... done
testing port 9282... done
testing port 9284... done
testing port 9286... done
testing port 9288... done
testing port 9290... done
testing port 9292... done
testing port 9294... done
testing port 9296... done
testing port 9298... done
testing port 9300... done
testing port 9302... done
testing port 9304... done
testing port 9306... done
testing port 9308... done
testing port 9310... done
testing port 9312... done
testing port 9314... done
testing port 9316... done
testing port 9318... done
testing port 9320... done
testing port 9322... done
testing port 9324... done
testing port 9326... done
testing port 9328... done
testing port 9330... done
testing port 9332... done
testing port 9334... done
testing port 9336... done
testing port 9338... done
testing port 9340... done
testing port 9342... done
testing port 9344... done
testing port 9346... done
testing port 9348... done
testing port 9350... done
testing port 9352... done
testing port 9354... done
testing port 9356... done
testing port 9358... done
testing port 9360... done
testing port 9362... done
testing port 9364... done
testing port 9366... done
testing port 9368... done
testing port 9370... done
testing port 9372... done
testing port 9374... done
testing port 9376... done
testing port 9378... done
testing port 9380... done
testing port 9382... done
testing port 9384... done
testing port 9386... done
testing port 9388... done
testing port 9390... done
testing port 9392... done
testing port 9394... done
testing port 9396... done
testing port 9398... done
testing ports [10600..10998]... done
testing port 10600... done
testing port 10602... done
testing port 10604... done
testing port 10606... done
testing port 10608... done
testing port 10610... done
testing port 10612... done
testing port 10614... done
testing port 10616... done
testing port 10618... done
testing port 10620... done
testing port 10622... done
testing port 10624... done
testing port 10626... done
testing port 10628... done
testing port 10630... done
testing port 10632... done
testing port 10634... done
testing port 10636... done
testing port 10638... done
testing port 10640... done
testing port 10642... done
testing port 10644... done
testing port 10646... done
testing port 10648... done
testing port 10650... done
testing port 10652... done
testing port 10654... done
testing port 10656... done
testing port 10658... done
testing port 10660... done
testing port 10662... done
testing port 10664... done
testing port 10666... done
testing port 10668... done
testing port 10670... done
testing port 10672... done
testing port 10674... done
testing port 10676... done
testing port 10678... done
testing port 10680... done
testing port 10682... done
testing port 10684... done
testing port 10686... done
testing port 10688... done
testing port 10690... done
testing port 10692... done
testing port 10694... done
testing port 10696... done
testing port 10698... done
testing port 10700... done
testing port 10702... done
testing port 10704... done
testing port 10706... done
testing port 10708... done
testing port 10710... done
testing port 10712... done
testing port 10714... done
testing port 10716... done
testing port 10718... done
testing port 10720... done
testing port 10722... done
testing port 10724... done
testing port 10726... done
testing port 10728... done
testing port 10730... done
testing port 10732... done
testing port 10734... done
testing port 10736... done
testing port 10738... done
testing port 10740... done
testing port 10742... done
testing port 10744... done
testing port 10746... done
testing port 10748... done
testing port 10750... done
testing port 10752... done
testing port 10754... done
testing port 10756... done
testing port 10758... done
testing port 10760... done
testing port 10762... done
testing port 10764... done
testing port 10766... done
testing port 10768... done
testing port 10770... done
testing port 10772... done
testing port 10774... done
testing port 10776... done
testing port 10778... done
testing port 10780... done
testing port 10782... done
testing port 10784... done
testing port 10786... done
testing port 10788... done
testing port 10790... done
testing port 10792... done
testing port 10794... done
testing port 10796... done
testing port 10798... done
testing port 10800... done
testing port 10802... done
testing port 10804... done
testing port 10806... done
testing port 10808... done
testing port 10810... done
testing port 10812... done
testing port 10814... done
testing port 10816... done
testing port 10818... done
testing port 10820... done
testing port 10822... done
testing port 10824... done
testing port 10826... done
testing port 10828... done
testing port 10830... done
testing port 10832... done
testing port 10834... done
testing port 10836... done
testing port 10838... done
testing port 10840... done
testing port 10842... done
testing port 10844... done
testing port 10846... done
testing port 10848... done
testing port 10850... done
testing port 10852... done
testing port 10854... done
testing port 10856... done
testing port 10858... done
testing port 10860... done
testing port 10862... done
testing port 10864... done
testing port 10866... done
testing port 10868... done
testing port 10870... done
testing port 10872... done
testing port 10874... done
testing port 10876... done
testing port 10878... done
testing port 10880... done
testing port 10882... done
testing port 10884... done
testing port 10886... done
testing port 10888... done
testing port 10890... done
testing port 10892... done
testing port 10894... done
testing port 10896... done
testing port 10898... done
testing port 10900... done
testing port 10902... done



starting service.. done
 
How are the phones provisioned.
 
3cx app softphone. I have 4 sip trunks.
 
Are you using a support SIP trunk?
 
I believe its unsupported.

TPG sip trunk.

Reading online suggests they only support G.711 A-Law audio codec. I have now deleted the other codecs in options
 
So the problem is still occuring. Its only happening on 2 different sites with Windows 11. We have a third site with Windows 10 and it has never happened.

I did get audio to work on a call by pressing the Windows media play pause key. But I haven't experimented enough to know if this is a real solution.

What do I need to do to investigate this further? I have seen some people using wireshark to track diagnostic information for calls should I try something like this?
 
I found an error using wireshark:

No | Time | Source | Destination | Protocol | Length | Info
1 0.000000 192.100.63.14 52.142.76.111 TLSv1.2 137 Application Data
2 0.000058 192.100.63.14 52.142.76.111 TLSv1.2 1528 Application Data
3 0.013394 52.142.76.111 192.100.63.14 TLSv1.2 96 Application Data
4 0.015852 52.142.76.111 192.100.63.14 TLSv1.2 104 Application Data
5 0.015852 52.142.76.111 192.100.63.14 TLSv1.2 795 Application Data
6 0.015852 52.142.76.111 192.100.63.14 TLSv1.2 92 Application Data
7 0.015909 192.100.63.14 52.142.76.111 TCP 54 49187 → 443 [ACK] Seq=1558 Ack=822 Win=1023 Len=0
8 0.109102 52.142.76.111 192.100.63.14 TLSv1.2 227 Application Data
9 0.155544 52.142.76.111 192.100.63.14 TLSv1.2 104 Application Data
10 0.278201 52.142.76.111 192.100.63.14 TCP 104 [TCP Retransmission] 443 → 62488 [PSH, ACK] Seq=224 Ack=1 Win=482 Len=50
11 0.546189 52.142.76.111 192.100.63.14 TCP 327 [TCP Retransmission] 443 → 62488 [PSH, ACK] Seq=1 Ack=1 Win=482 Len=273
12 2.146222 52.142.76.111 192.100.63.14 TCP 327 [TCP Retransmission] 443 → 62488 [PSH, ACK] Seq=1 Ack=1 Win=482 Len=273

13 2.146239 192.100.63.14 52.142.76.111 TCP 66 62488 → 443 [ACK] Seq=1 Ack=274 Win=1025 Len=0 SLE=1 SRE=274
14 6.331204 52.142.76.111 192.100.63.14 TLSv1.2 120 Application Data
15 6.372520 192.100.63.14 52.142.76.111 TCP 54 62488 → 443 [ACK] Seq=1 Ack=340 Win=1025 Len=0

Wire shark says the problem is [TCP Retransmission] but everywhere I read online says the problem could be anything

Windows Defender firewall settings looked a bit messy so I have deleted them all and made them the same as this working example:
3cx-windows-defender-firewall-settings.png

I hope its as simple as windows defender blocking it...
 
I'm still getting the same problem even after changing windows firewall settings

17 0.220810 52.142.76.111 192.100.63.14 TCP 104 [TCP Retransmission] 443 → 55259 [PSH, ACK] Seq=224 Ack=1 Win=482 Len=50
18 0.496881 52.142.76.111 192.100.63.14 TCP 327 [TCP Retransmission] 443 → 55259 [PSH, ACK] Seq=1 Ack=1 Win=482 Len=273
19 1.000007 Microsof_2d:5e:01 Spanning-tree-(for-bridges)_00 LLDP 67 LA/DESKTOP-J8BA92C MA/00:2d:5e:01:af:0f 3601
20 1.040878 52.142.76.111 192.100.63.14 TCP 327 [TCP Retransmission] 443 → 55259 [PSH, ACK] Seq=1 Ack=1 Win=482 Len=273

There is a post here (https://www.3cx.com/community/threads/audio-drops-pause-for-user-s-part-4.85378/#post-401267)
saying:
[TCP Retransmission] usually means that you have packet loss (so it was retransmitted because no ack). It jives with garbled audio, out of sync audio, audio "catching up", etc.

Try a continuous ping from the affected machine to the 3CX server. Are you dropping packets?
Also one to the AP, to the router, and to some site externally. Depending on what drops you will learn it's AP, it inside the network, it's internet specific, etc.

Anybody know how to do a "continuous ping"?

I tried ping <server IP address or hostname> -t

but only got:

Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.

The problem seems to only be happening from 1 out of 3 DID softphones now.​

 
Last edited:
We upgraded our Windows 10 pc which has never had this problem to Windows 11 and its now had its first incoming call with no audio.

This pc is in a different state to the other one having problems.

wireshark:

27 0.149012 pbx pc TLSv1.2 104 [TCP Previous segment not captured] , Application Data
28 0.149038 pc pbx TCP 66 [TCP Dup ACK 22#1] 49245 → 443 [ACK] Seq=1 Ack=51 Win=1024 Len=0 SLE=222 SRE=272
29 0.150795 pbx pc TCP 225 [TCP Out-Of-Order] 443 → 49245 [PSH, ACK] Seq=51 Ack=1 Win=482 Len=171

Anyone know if 3cx has a good troubleshooting guide? Seems like they don't use this forum....

3cx-network-sip-transport.png
I'm going to start experimenting with any settings I can find. Changed the SIP Transport from UDP to TCP...

Waiting game now.
 
Dont start changing settings without knowing what it does otherwise you'll end up chasing your tail and could introduce more problems.

Start with basic troubleshooting.

a) is PBX spec sufficient
b) does firewall test pass
c) can I replicate this issue making internal calls and echo test? *777
d) does this only happen on external calls?

If it only happens when calls are over your SIP provider you then need to perform additional tests. You must test until you can replicate.

a) does this happen when using the 3CX mobile app?
b) What is the symptom? One way audio or loss of audio both ways?
c) Turn on call recording, can you hear anything when you play back?
d) wireshark capture a problem call and review

Basically, the first thing id be doing is trying to replicate the issue and then seeing if it happens on the mobile app.
 
  • Like
Reactions: StanleyS
Start with basic troubleshooting.

a) is PBX spec sufficient 3cx AWS install
b) does firewall test pass Yes (1st post)
c) can I replicate this issue making internal calls and echo test? *777 Yes works fine
d) does this only happen on external calls? Yes (we don't use internal)

If it only happens when calls are over your SIP provider you then need to perform additional tests. You must test until you can replicate.

a) does this happen when using the 3CX mobile app? No
b) What is the symptom? One way audio or loss of audio both ways? Both (until we forward call to another extension)
c) Turn on call recording, can you hear anything when you play back? Not available
d) wireshark capture a problem call and review Posted above

Basically, the first thing id be doing is trying to replicate the issue and then seeing if it happens on the mobile app.

We have been using the webclient and do not get this issue. Problem seems to be Windows app only
 
Does ticking "PBX delivers audio" in SIP trunk make any difference?
 
Just keep in mind that the firewall checker tests the first and last ports, not the whole audio range.

So in case the entire range is not forwarded correctly, when the ports eventually increment enough to reach the ones that are blocked, you will have audio issues. People who usually face this tend to mention that restarting the services temporarily fixes this (since the RTP range resets from the beginning).

- Do you have the issue only on external calls via Trunk or is it also affecting internal calls?
- What is your app version number?
- What is your PBX version number?
 
Does ticking "PBX delivers audio" in SIP trunk make any difference?
It was originally ticked. We have unticked it but haven't noticed a difference.
 
Just keep in mind that the firewall checker tests the first and last ports, not the whole audio range.

So in case the entire range is not forwarded correctly, when the ports eventually increment enough to reach the ones that are blocked, you will have audio issues. People who usually face this tend to mention that restarting the services temporarily fixes this (since the RTP range resets from the beginning).

- Do you have the issue only on external calls via Trunk or is it also affecting internal calls?
- What is your app version number?
- What is your PBX version number?
- Do you have the issue only on external calls via Trunk or is it also affecting internal calls? We don't make internal calls but will start testing that
- What is your app version number?
3CX Desktop App
Version:18.12.425

- What is your PBX version number?
18.0 (Build 312)

Just keep in mind that the firewall checker tests the first and last ports, not the whole audio range.

So in my first post i have firewall results. Does that mean the audio ports are:

testing ports [9000..9398]?
testing ports [10600..10998]?

In my wireshark log posted above, is the phone call trying to use port 62488? If its 62488 does that mean its above my port range?

How can I do a better test then? In 3cx Dashboard there is a 'Terminal' button which opens console. Should I use that?

I am using AWS to host 3CX
 
So in my first post i have firewall results. Does that mean the audio ports are:

testing ports [9000..9398]?
testing ports [10600..10998]?

The audio ports are 9000-109999 and you should only open them on the AWS side (not on your PCs).
If you deployed it automatically in AWS via 3CX then we already opened the ports for you and you do not need to touch anything at all.


In my wireshark log posted above, is the phone call trying to use port 62488? If its 62488 does that mean its above my port range?
This might get confusing but I promise it's simple:

  • The server talks and listens via 9000-109999
  • The clients can talk and listen from any random TCP port - this is perfectly normal so don't worry about it.
  • They don't both have to be on the same range, ports work independently of each other.
  • Think of it like neighbors on two buildings: I can shout from my first floor, and you can shout from your 3rd floor and we can still talk to each other just fine.

No what we don't know is if you have internet connectivity issues between the PC and and the AWS server, causing your issues or if your trunk provider has issues. Some TCP retransmissions will not lead to any noticeable problems, but too many retransmissions often indicate that you have a network issue (ie. the data is not flowing, and you will notice audio problems for sure). More typical on WiFi, so do whatever you need to do to ensure a stable connection on the PC.

My guess is that you simply have an unstable internet connection and from time to time you lose audio. If you enable recordings in 3CX you can quickly find out by listening to the recording

- If the other side sounds well in the recording, but you couldn't hear them, then the connection between 3CX and your PC is the issue.

- If you hear yourself fine in the recording, but cannot hear the other side, then the connection between 3CX and provider is the issue.
 
My guess is that you simply have an unstable internet connection and from time to time you lose audio.
We don't have unstable internet. We have tried different lan cables, ports

We don't have problems with any other internet service.

Its only happening at one of our locations on a Windows 11 desktop app.

It does not happen on the same computer using 3cx webbrowser version in google chrome

We have never had a problem making outbound calls from this computer

It only happens on inbound calls. Some weeks its fine other weeks its really bad.

Whats making it difficult for me to diagnosis is that I really can't find a clear path to troubleshoot this.

We do see the error being captured in wireshark as posted above.

Currently the only solution we have is if we answer a call with no audio then we forward it to another extension.

Does 3cx have better troubleshooting information? I'm really keen to test all points of failure starting with the windows 11 pc, the 3cx server and the SIP provider
 
Hi @yogasensai as you mentioned this issue is only with the external calls and not with the internal calls, I suggest you to test with a supported VoIP Provider and let us know if experience the same issue or not.

Otherwise, if you want to keep the unsupported sip trunk you will need to contact them for troubleshooting their trunks.
 
  • Like
Reactions: YiannisH_3CX
It only happens on inbound calls. Some weeks its fine other weeks its really bad.

Whats making it difficult for me to diagnosis is that I really can't find a clear path to troubleshoot this.

We do see the error being captured in wireshark as posted above.

Currently the only solution we have is if we answer a call with no audio then we forward it to another extension.

Does 3cx have better troubleshooting information? I'm really keen to test all points of failure starting with the windows 11 pc, the 3cx server and the SIP provider
Here you go: https://www.3cx.com/3cxacademy/advanced/

In my opinion the best way to go about this is to hire a partner to help you troubleshoot. Alternatively you will need to keep a tshark capture running and once the issue occurs troubleshoot using the capture.
The errors you are seeing above don't really tell us anything as that could be anything especially out of context. You will need to see the SIP messages, check that the RTP ports used are correct and move from there. Then you can export the audio in both directions and see if audio is indeed present.
 
I am reporting that the issue has been solved.

We updated to V20 and now the problem is gone. One thing that could of been the cause was that V20 forced us to upgrade our hardware minimum requirements which was easy to do because we are using AWS.
 
  • Like
Reactions: jed
Status
Not open for further replies.

Forum statistics

Threads
111,973
Messages
590,071
Members
164,892
Latest member
Phone1stStop