Jump to content

Poll - Are your end customers using STUN with their SIP-trunks


Dernis

Recommended Posts

Are your end customers using STUN with their SIP-trunks?

Please go here to vote:

http://goo.gl/x1YrMm

 

Please leave any comments in this thread.

 

Did you know that SwyxWare's LinkMgr does not support DNS SRV for STUN?

This means that LinkMgr cannot failover to another STUN-server if the current STUN-server becomes unavailable.

The result is that the SIP-trunk will go down.

 

LinkMgr has support for DNS SRV when it comes to SIP-trunks.

But this does not help when you have activated STUN on the SIP-trunk.

Link to comment
Share on other sites


8 minutes ago, Virikas said:

Just put your STUN server behind a load balancer (identified by an A record) and you won't need an SRV record ;)

 

Why should the Swyx Distributor/Reseller or end customer have to create their own STUN service in this maner when the provider/carrier already have several STUN-servers available and published via DNS SRV-records?

 

If LinkMgr supported DNS SRV for STUN - then the SwyxWare Distributor/Reseller or end customer could create their own list of public STUN-servers using DNS SRV-records.

This would be much easier than hosting and running your own STUN servers as suggested.

 

LinkMgr already supports DNS SRV for SIP-trunks, why is this not also implemented for STUN?

 

Link to comment
Share on other sites


2 minutes ago, Virikas said:

I'd assume that this is an hen and egg problem.;)

So you might file a feature request towards swyx.

 

Well, I do not like using STUN in the first place - since it's yet another source for potential failure and adds unessary overhead (classic stun messaging).

 

The whole problem with SIP not natively supporting NAT-T could easaly be solved if there was a way to just tell LinkMgr about the public IP-address. So LinkMgr will replace the private IP-address in SIP/SDP with the public one before sending it off to the provider (in the same way LinkMgr does this when activating STUN. However - port does not need to be replaced, only the IP-address).

 

All you have to do then, besides telling LinkMgr about the public IP-address, is to create two portforwarding rules in your firewall that allows incoming traffic from your provider to:

* SIP port 65002

* RTP 55000-56000

 

Problem solved and it will work with every provider - even thoose that do do offer STUN or SBC with NAT-T support.

This is the feature I really want for the LinkMgr.

 

Comments?

:)

 

PS.

This solution will however not work for customers with a DHCP address from their ISP.

Thoose customers still needs to rely on either STUN or provider with an SBC supporting NAT-T.

All our customers have static IP's since we only work with medium and large companies.

 

 

 

Link to comment
Share on other sites


  • 8 months later...

I agree with Dernis - Some other PBXs that I have worked with give options to manually set the public IP address, negating the need for STUN. I would also say that I have encountered many STUN related problems over nearly 10 years of using Swyx with SIP trunks. removing the need for this would make life a lot simpler. I do feel that allowing optional manual entry of public IP in Swyx server trunk settings would be a big improvement.

Link to comment
Share on other sites


Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and have taken note of our Privacy Policy.
We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.