Dernis Posted February 23, 2016 #1 Share Posted February 23, 2016 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 More sharing options...
Most Valued User Virikas Posted February 24, 2016 Most Valued User #2 Share Posted February 24, 2016 Just put your STUN server behind a load balancer (identified by an A record) and you won't need an SRV record Link to comment Share on other sites More sharing options...
Dernis Posted February 24, 2016 Author #3 Share Posted February 24, 2016 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 More sharing options...
Most Valued User Virikas Posted February 25, 2016 Most Valued User #4 Share Posted February 25, 2016 I'd assume that this is an hen and egg problem.;) So you might file a feature request towards swyx. Link to comment Share on other sites More sharing options...
Dernis Posted February 25, 2016 Author #5 Share Posted February 25, 2016 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 More sharing options...
5wyx1t Posted November 15, 2016 #6 Share Posted November 15, 2016 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 More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.