Solved UDP Port 9000 Cone Test Fails (SIP ALG)

[Avram Grossman]

Outgoing calls always go thru but very often with no Voice. This would indicate UDP ports. I had the network admin ensure 9000-10999.
Firewall test fails at UDP 9000 only. Since the network guy said he opened all the ports as requested, I changed the parameter FirstExtPort to 9002.
Rebooted and retested. Now 9002 fails cone test. I change to 9010 just for grins, and only the first port, port 9010 fails. Restored to Port 9000 and searching for a solution.

When an outbound call does connect via voice, redial always rings with voice. When an outbound call to a number that rings and answers but has no audio, redial to that number always fails to pass voice.
Assuming the UDP audio ports were assigned randomly with each I would expect more calls to complete with audio. I'm stumped as to why the first UDP port in the Firewall test fails, regardless of FirstExtPort value. And how to resolve this issue. Incoming calls seem to pass audio okay.

 

[SweetAction]

I'd advise you take a packet capture and see what's happening during the FW test. I've had the test bug out before but no real issues but it will also shed some light as to what's happening.

 

[Avram Grossman]

So far no success. Call to some numbers (mainly mobile phones) do have audio.
Most outbound calls connect to calling party but with NO audio.
as mentioned above, the Firewall Full Cone test fails but seems to skip over the "first" valid port address as set in the FirstExtPort variable. Strange. I suspect most outbound calls are wanting to use Port 9000 first. Any ideas?

 

[JohnS_3CX]

The firewall tester checks the low and high ports, not the entire range so you may have more problematic ports than you think - just FYI.

the Firewall Full Cone test fails

This is a warning sign - if you are seeing failures, you can be fairly certain the network is misconfigured, justifying the audio issues.

but seems to skip over the "first" valid port address as set in the FirstExtPort variable

this appears counterintuitive, precisely because the firewall is misconfigured and will allow some to pass while blocking others.

I suspect most outbound calls are wanting to use Port 9000 first

Not quite - the entire range gets used. The PBX starts low and increments as you make further calls so don't assume you will know what port your calls will use.

The firewall setup may not be enough, you could be behind a double NAT or the port forwards may have not been done properly, or the forwards were done using a method that isn't full-cone, or you could also have a firewall that isn't bridged directly to the internet (ISP modem may be doing things after traffic leaves firewall). Either way, you will need to do a bit of sleuthing on the network level, and could benefit from someone with more experience on the network setup of 3CX.

Consider hiring a 3CX Partner to help you troubleshoot this with your network guy and get things set up correctly.
https://www.3cx.com/ordering/find-reseller/

 

[Avram Grossman]

doing lots of testing, this is occuring on two installations. both installations where were working just for several years, until a recent update. Ports forwarding in either firewalls were not changed. What is suspecious is 1) only outbound call audio is affected. Inbound audio calls are fine. 2) the Firewall Test always fails on just the first port number - 9000. If I change FirstExtPort to 9010 for example, then 9010 fails. Again, this is on two installs that were working just fine and had no firewall changes made. Only software updates. Currently running Version 18 Update 4 Build 965.

Additional tests: dialing my mobile # always connects with audio. Dialing my home number rings in the UK. Dailing my office number...silence with an occassional ring-thru. ALL PORTS ARE OPEN

 

[JohnS_3CX]

both installations where were working just for several years

..and yet, the fact that it worked before still doesn't tell us absolutely anything about why it doesn't work now.

This is a common troubleshooting pitfall (which I am also guilty of ). If you are going to troubleshoot, then do it blindly as if this is the first time you've come across this system and don't assume prior knowledge that can get in your way.

Depending on your available time and level of knowledge:

a.) Read how the firewall checker works, and get ready for a lot of wireshark. This will inform you what happens each time the PBX tries to send audio, and lead you to find why this occurs through a process of elimination. SIP and SDP knowledge required here https://www.3cx.com/docs/firewall-checker/

b.) Try something simple: remove all port forwards entirely and redo them from scratch (just in case - you never know)
https://www.3cx.com/docs/ports/

c.) If the above did not get you anywhere, it's time to call in the experts: hire an experienced 3CX Partner - they will know where to look, and what to look for and can save you valuable time and effort!

 

[Avram Grossman]

I hope my solution is fodder for thought. After weeks trying to figure out why the first port 9000 was failing the cone test, I found the solution. And yes the Firewall Test program is correct. While this started happening on two of my installs that have been working for years, it might be that the latest 3CX updates are more stringent. The cable modem/firewall setting for SIP ALG needed to be turned off. This was causing the first port request to get dinged. With SIP ALG disabled calls are going thru. My other install requires a new DOCSYS 3.1 modem as the current installed version does not support SIP ALG options. Phew. Happy customers. But it was difficult to find this one!