To STUN or Not to STUN

I am often asked how many people read this blog. The fact is I have no idea. The blog is posted with PhonePlus,  VON/xchange, TMCnet's IP Communications and SIP Trunking communities, Telecom Reseller, and Broadvox. The target audiences for the blogs are our current VAR partners, potential partners and from time to time the end-user community. Generally, I discuss something relevant to the IP Community that has mass appeal such SIP Trunking, UC, HD Voice, net neutrality, etc. Yesterday when I decided to blog about the issues we were having with a STUN Server and our Avaya customers, it was for a much more narrow audience.

An unknown STUN server was causing service interruptions and some of our VARs and customers were very upset with us. Losing phone service is very disruptive to a business and we were unable to explain why they were suddenly unable to complete calls. In addition to the usual comments about accepting responsibility, we were also accused of not being certified with the Avaya platform. Ultimately this results in a loss of confidence with the VARs and a loss of business with our customers. I wrote the STUNning Unnecessarily blog to inform that audience of the problem. However, my intent was with regard to the Broadvox channel and its customers and not creating an issue with Avaya. Nevertheless, I did receive a call from an Avaya representative. Unfortunately, I was in a meeting and he left a message. He was interested in reviewing the issue of the STUN server and finding resolution. As I had not heard of such a server until yesterday, I passed him off to the head of our SIP Engineering group. They had a very useful conversation and we believe Avaya will address their default configuration settings, as well as, how they support DevConnect Partners such as Broadvox during an emergency. So, some good came out of the blog.

Now back to the question...To STUN or not to STUN? In reading a series of blogs this morning, apparently, it is not necessary to enable STUN if your service provider utilizes SBCs in their network. Broadvox employs Sonus SBCs throughout its network and should therefore customers should not have to enable STUN. I was hoping for a few comments to the blog, but alas, I got only one looking forward to the answer of the question. If there are other opinions on whether to enable STUN, I would appreciate knowing.

See you on Monday with another original recipe and talk of IP.