Jump to content

STUN + Phone local IP contact addresses etc


Scott1234

Recommended Posts

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?
 

Link to comment
Share on other sites

  • Scott1234 changed the title to STUN + Phone local IP contact addresses etc

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. 

Link to comment
Share on other sites

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. 

 

 

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...