What is the significance of "LOCALSUBNETS" in parameters

[Gav]

a bit of background to my question.
We have 3CX 15.5.
Using Fanvil X4 phones.
Our server and phones live in the subnet 192.0.0.0/21
We have a an audio problem with our phones whereby at the start of some but not all calls we suffer a brief audio drop. Regardless of if the call is internal or external. After this drop the calls are perfect for the length of the call.

I've tried loads of things to try and correct this issue and my thoughts keep coming back to some kind of networking issue.
It's almost as if the start of each call the phone audio is taken from the server and 'handed' to the fanvil phone.

IE - during the ringing stage the server handles the audio, then when the phone is picked up at the ringing end, some kind of discussion takes place between calling phone, receiving phone and the server where the server 'hands' the call over...And during this handover we lose audio.
Please bear in mind this is all theoretical and I could be way off the mark, but I'm seriously running out of ideas.

My understanding is the phones should be making the connection direct from handset to handset? And so why would they suffer an audio drop?
The only thing that is making me question our setup is the fact we aren't using a true private subnet as per "LOCALSUBNETS" parameter.

My question is what effect does this have on the internal workings of 3CX?
Could this create problems like I've described?
I know I could rebuild our network to be a true private IP range but this would be an incredibly difficult task, not just for 3CX but for all the other internal applications we run.
So before I destroy my entire network and create myself headaches for weeks, I'd like know if all this stress and hassle is really going to make a change to 3CX?

 

[eddv123]

This setting are the local subnets supported by 3CX (RFC Compliant subnets) that you can run the local PBX on. https://tools.ietf.org/html/rfc1918

You can add extra subnets into this (non-RFC compliant subnets) but I would not recommend this.

I have tested this myself and where initially this worked and seemed OK there were a lot of issues in regards to remote calls/remote connections and especially using the Smartphone 3CX Apps.

Keep within the supported subnets if you can, although I am aware that in the real world some sites will have other subnets out of these ranges.

 

[eddv123]

In regards to your issue itself, it does sound a little like Voice Clipping (which is common when using PSTN gateways) and is often solved by enabling "early media" on your VoIP gateway - but if it occurs on internal calls also then its not this.

I would have to go with network also - however as a test have you seen if the same behavior occurs when using the soft-client for Windows ?

Failing that get a wireshark capture of the audio and see if it give you any clues.

 

[YiannisH_3CX]

Hello @Gav

I have a question about how the phones are provisioned to the PBX as the PBX should not consider them to be "local" devices. Did you auto provision the phones as local or remote or did you manually register them to the PBX?
Since you are using a non local subnet then the PBX will consider the extensions remote and all traffic will go through your firewall as the PBX will add its public IP in the SDP. Most firewalls do no allow loop back traffic so the fact that you actually have audio is pretty lucky. This however puts unnecessary strain on your firewall as all traffic even extension to extension will be routed through the firewall. The best option as @eddv123 suggested is to use an RFC complaint subnet.

 

[Gav]

Hi Yiannish

I auto provision the handsets.

When I do a wireshark trace I don't see traffic going to the firewall, I only see traffic going between the PBX and handsets. So is it completely true that our deskphones are routing via the router?

As a test I've been using the 3cx softphone this morning to make and receive calls, both internal and external calls. I've not had a single audio dropout with this.
So clearly this is something to do with how the fanvil handsets present themselves on the LAN.