Yealink T54W No audio on LAN between other IP Phones

[MSET]

I'm fairly sure this has nothing specifically to do with the yealink phones, rather how 3cx handles IP phones in general (speculating at this point).

I recently have implemented hairpin NAT for our 3cx server to avoid split-dns for LAN and WAN clients. This is working as expected so far. Clients connect to the PBX via the public IP of the PBX, even when internal. The only downsides to this are:

• All traffic must now go through our WAN router, this is acceptable
• The PBX sees all LAN clients connecting from the WAN routers' LAN IP on its subnet due to NAT. For example, if the PBX is at 192.168.0.10 and a LAN client is at 192.168.4.20, the LAN Client connects to the PBX via a public IP, say 132.132.132.129. The PBX sees the connection coming from the WAN's IP at 192.168.0.1. So, all LAN connections look like they are coming from one IP. I'm not sure if this really causes any problem, except obviously that the PBX has no way to directly initiate connections with a LAN phone/client.

The symptoms of the problem:

• IP Phone to IP Phone, no audio either direction.
• App (desktop or mobile) to/from IP Phone. No issues.
• Public number to/from IP Phone. No issues.
• App (desktop or mobile) to/from each other or public number. No issues.
• Echo test (*777) from IP phones work fine. No issues.

I'll also note that I'm certain I've covered all the necessary ports (including the LAN RTC ports 7000-8999) in my NAT configuration and firewall rules.

My guess is I have created a scenario where my IP phones are now "remote" and require something like STUN to receive connections from the PBX, but the behavior I am seeing is leaving me a bit uncertain. The IP Phones calling each other ring and connect without issue. Echo tests work fine. Is this expected for "remote" IP phones without any special config? What kind of solution might help me here?

 

[SteveITS]

Your STUN comment was my first thought as well. If you back up a bit though, why avoid split DNS? That connects the device to the server directly and avoids any NAT or port forwarding (STUN) issues. It's their documented method...https://www.3cx.com/docs/creating-fqdn-split-dns/

 

[MSET]

Your STUN comment was my first thought as well. If you back up a bit though, why avoid split DNS? That connects the device to the server directly and avoids any NAT or port forwarding (STUN) issues. It's their documented method...https://www.3cx.com/docs/creating-fqdn-split-dns/

Believe me... I'd prefer split DNS. We do business with enough customers that have us using a certain VPN client that often enforces a certain DNS security tool that hijacks a systems DNS (cisco umbrella). This sort of thing is becoming more common for us. If you don't manually turn this service back off, it often continues running indefinitely. Basically, users' desktop phones will get stuck trying to connect via the public IP even when on LAN, so hairpin NAT eliminates this problem.

We have less than 10 physical phones compared to 40+ softphones active, and the physical phones don't actually call each other very often. I've traded one devil for another. At this point I'm hoping to find a way to get the desk phones working properly and leaving my NAT config in place.

 

[JohnS_3CX]

Firstly, let me say that this is not a supported scenario to run your PBX in. There may be further issues that you will discover later. The PBX is designed to handle traffic differently, depending on whether it comes from a private or public IP.

You are now effectively converting local traffic to public, and then back to local again, but hiding the fact that this is happening. The IPs are probably being re-written in such a way that the packet appears to come from 192.168.0.10, yet the SIP messages contained within the state a different address range 192.168.4.20 and this makes a mess of the audio packets.

You can try to enable the option PBX Delivers Audio under the extensions that have the issue, and it may solve your problem for the time being, but keep in mind that even if it works, this is just a bandaid and the setup is still running in a way that was not intended.

 

[MSET]

Firstly, let me say that this is not a supported scenario to run your PBX in. There may be further issues that you will discover later. The PBX is designed to handle traffic differently, depending on whether it comes from a private or public IP.

You are now effectively converting local traffic to public, and then back to local again, but hiding the fact that this is happening. The IPs are probably being re-written in such a way that the packet appears to come from 192.168.0.10, yet the SIP messages contained within the state a different address range 192.168.4.20 and this makes a mess of the audio packets.

You can try to enable the option PBX Delivers Audio under the extensions that have the issue, and it may solve your problem for the time being, but keep in mind that even if it works, this is just a bandaid and the setup is still running in a way that was not intended.

I appreciate the response. Can you comment at all how the mobile and desktop apps are functioning correctly? Are they doing something different from the physical IP phones? I assume they *always* relay through the PBX, or they are smarter about detecting when a direct LAN connection seems not possible.

I enabled "PBX Delivers Audio" and it seems to have allowed the IP phones to send audio between them now, so thank you for the advice. Ideally, I wouldn't have had to do this, but not having 100% control over your LAN DNS at all times does make split-dns not such a slam dunk solution.

 

[JohnS_3CX]

Hello,

Yes they are very different, to explain a little better, the apps (which are custom software we write) use the 3CX tunnel or a direct HTTPS connection. This means that the are more fault tolerant to NAT issues and might "get away with it" even under these network conditions.

IP phones on the other hand cannot use the custom 3CX Tunnel, and they rely on proper networking and proper SIP signalling in order to operate.

A possible solution would be to have a 3CX SBC on the same network as the phones (so it's truly local traffic as opposed to your network which isn't true local traffic due to the NAT) and the SBC then establishes its own tunnel connection to the PBX similar to the apps. It allows phones (on the same network) to work without PBX Delivers Audio and will probably be a slightly "less wrong" way of running your current setup.

 

[MSET]

Hello,

Yes they are very different, to explain a little better, the apps (which are custom software we write) use the 3CX tunnel or a direct HTTPS connection. This means that the are more fault tolerant to NAT issues and might "get away with it" even under these network conditions.

IP phones on the other hand cannot use the custom 3CX Tunnel, and they rely on proper networking and proper SIP signalling in order to operate.

A possible solution would be to have a 3CX SBC on the same network as the phones (so it's truly local traffic as opposed to your network which isn't true local traffic due to the NAT) and the SBC then establishes its own tunnel connection to the PBX similar to the apps. It allows phones (on the same network) to work without PBX Delivers Audio and will probably be a slightly "less wrong" way of running your current setup.

Yeah, I think I'll set up an SBC VM for the long-term solution as the extension option is more administrative work and not at all obvious. I am then considering putting my PBX on a separate public-only subnet (DMZ) such that it has no LAN connection at all to the office. Basically, treating it like a remote PBX for everything, as it would be if it was hosted in the cloud or somewhere else. Would remove the need for the hairpin NAT as well and put it back into a "supported" configuration I think.

 

[JohnS_3CX]

Yes, I think that would probably work best for your case, as the devices and apps can reach it the same way they would reach a public PBX without "fudging" the true IPs.