Stun.3cx.com down?

[Tindalos]

We're in the process of a 3CX phone system rollout that will handle our remote sales. I'm using Cisco 525G2s and everything works great but they dropped off about an hour ago and I've tracked it down to an issue with the stun.3cx.com server. stun3.3cx.com works and I've verified with 3G, but the problem I have now is that all my Cisco phones have hardcoded stun.3cx.com in them.

IP address: 96.9.132.83
Host name: stun.3cx.com

Alias:
stunserver.siptesting.net
stun.3cx.com
96.9.132.83 is from United States(US) in region North America


TraceRoute to 96.9.132.83 [stun.3cx.com]

Hop (ms) (ms) (ms) IP Address Host name
1 0 0 0 206.123.64.154 -
2 0 0 0 64.124.196.225 xe-4-2-0.er2.dfw2.us.above.net
3 0 0 0 63.218.23.29 ge5-4.br02.dal01.pccwbtn.net
4 Timed out Timed out Timed out -
5 Timed out Timed out Timed out -
6 Timed out Timed out Timed out -


Is there a better way to do this? Can I setup our own STUN server, or not use one? Or should I setup stun.ourcompany.com so I can control this through CNAME records as an alias to redirect in case something happens like this in the future?

Thanks for the help, happy to be here!

 

[davidbenwell]

Hi, do you have a static IP address for your connection? if so you can turn the stun server off.

 

[eagle2]

Hi Tindalos,

Just an idea -- if you have a static public address for your 3CX Phone System -- simply switch STUN off and use external static IP address where necessary in settings.

For your Cisco Linksys phones you may also not use STUN -- configure the phones manually and delete STUN settings (in the SIP tab) and don't use NAT mapping (into Line 1 tab). Instead of using STUN in the phones, go to Advanced Settings in your 3CX Phone System, Custom Parameters and set 'ALLOWSOURCEASOUTBOUND' to 1. In version 10 this setting is set to '1' by default (see post on the topic: http://www.3cx.com/blog/docs/3cx-phone-system-parameters-table/, as pointed by Stepan in other post: http://www.3cx.com/forums/no-incoming-calls-19487.html ).

This is a powerful mechanism, similar or the same like used widely in Asterisk systems and so called Session Border Controllers. The main point behind is the way the SIP client address is processed in SIP messages (Contact, etc.). Normally, the discovered public addressort by STUN is substituted in SIP message. If no STUN is used (or no outbound proxy or tunnel) then the local address of the client is used into the SIP messages, which obviously makes return traffic impossible (no path). When the above parameter is set to true, the addressort into the SIP messages is replaced by the actual addressort from where the traffic is received -- the real addressort of the remote SIP client. This mechanism may not work in some complicated NAT environments in rare cases.

Please be aware of SIP ALG enabled NAT environments, some implementations may not work correctly. STUN will also not work correctly in most symmetric NAT environments, so the above strategy may prove successful in most cases.

Regards,
Orlin.

 

[Tindalos]

Sorry for taking a couple of days to get back, but I wanted to thank BOTH of you for an excellent answer.

Orlin - That's exactly what I've wanted to do, but I'm still somewhat new to VOIP implementations so my knowledge of STUN is limited. My first test of turning STUN off was a failure - but likely because of using NAT as well.

I have a failover DNS so turning STUN off and configuring the devices directly there would be excellent and allow me much more control over the environment. My only concern is that I just got 3CX Phone for iPhone working properly with 3G and most of that seems to be tied in through STUN. I'll take a little time to test this setting and follow your advice.
Thanks again! This is great information for people like me who aren't familiar with STUN.

Tindalos

 

[eagle2]

Thank you Tindalos,

have a look on this discussion (second half of the post): http://www.3cx.com/forums/no-incoming-calls-19487.html

STUN by idea is a good mechanism, the problem is unfortunately STUN is not an universal solution. You still need your public addressort coded into SIP messages. If the SIP client is unable to discover them (by STUN or other method), you may experience problems like one-way connectivity or one-way audio, etc. For example STUN is not working with some NAT environments correctly (mostly symmetric NAT implementations), so this could be a problem. Other problem is some clients are not supporting STUN, incorrect NAT implementations, etc.

Lack of universal solution, variety of clients and implementations, network environments are supposed to create lots of problems. SIP by idea is not originally intended to be used into NAT environment. This is the reason to exist several approaches to the problem. Asterisk implementations are ignoring by default the addressort coded into SIP/SDP messages, instead of this they are interested into addressort from which the message came (if not altered by an intermediate NAT device, it should be the correct address, discovered also by STUN), so Asterisk systems treat the SIP/RTP traffic like trivial IP traffic, which in most cases should do the job (and this is the basis of pretending being the only working system).

So, this is the idea behind the 'ALLOWSOURCEASOUTBOUND' parameter usage (default in Version 10). This should help in almost all cases. Using STUN simultaneously is not a problem. Leave your iPhone as is, if it is working. Check the remote phone status in 3CX management console and the address used in registration.

Regards