STUN + Phone local IP contact addresses etc

[Scott1234]

Does anyone know if this is a bad idea or not? For now, focusing only on Yealink phones and only hosted environments. 

By default, STUN is disabled in the PBX base Yealink config file, and when a phone connects, you see the local LAN IP in the contact, along with the device address being the WAN IP. 

When wire sharking, you see the SBC attempts to send audio to the local LAN IP along with the WAN IP. With STUN appropriately enabled, the phone will register with the wan IP in both the contact and device address and shows a clean result as it's not wasting time & resources trying to send to a LAN IP that will never work.

The only benefit of keeping the LAN IP is quickly finding a phone when remote supporting a customer you need to connect to. Is there any other reason? As it all appears to work including BLF's etc. 

Any unforeseen danger?
 

[Vodia Support EU]

Hello,

If I remember correctly, the communication in STUN is UDP based. I would have a problem with that.

 

[Vodia PBX]

You don't need STUN for NAT traversal. The PBX SBC takes care about it. Yes the PBX in the beginning sends the packets to the "advertised" address, but as soon as the first RTP packet from the phone hits the PBX, it will change the destination and "learn" the real IP address. STUN may help to make this a little faster, but it can also make things complicated for certain NAT types. IMHO it is not worth the trouble. 

[Scott1234]

Thanks, out of curiosity what NAT types does this make it more complex? 

I run non standard SIP ports to to prevent SIP ALG issues for customers who don't make sure their router implementation of SIP ALG is disabled, as I am over having to have customers make sure sip ALG is disabled, nothing but a nightmare. 

I notice MS Teams typically does not suffer this fait by using TLS. Only. and 5061 does not seem to be inspected like SIP 5060. 

 

 

[Vodia PBX]

There are NAT types that change the port if you send a packet to a different port on the same destination, though thinking about it this should not cause any issue because the PBX never changes the port. Luckily, the router industry has realized that VoIP is a reality today and have also improved their algorithms. Ultimately, WebRTC will pressure all manufacturers, and we don't have to worry about two-way audio any more. But until then it's a good idea to stay away from standard ports for VoIP, unfortunately.