Peer-to-Peer Blog: To STUN or Not to STUN

By David Byrd

I am often asked how many people read this blog. The fact is I have no idea. The blog is posted with PHONE+,  VON/xchange, TMCnets 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.

David Byrd is vice president of marketing and sales for

Broadvox

, and is responsible for marketing and channel sales programs to SMBs, enterprises and carriers as well as defining the product offering. Prior to joining Broadvox, David was the Vice President of Channels and Alliances for Eftia and Telcordia. As Director of eBusiness Development with i2 Technologies, he developed major partnerships with many of the leaders in Internet eCommerce and supply chain management. As CEO of Planet Hollywood Online he was a pioneer in using early internet technologies to build a branded entertainment and eCommerce website company partnered with Planet Hollywood. Having over twenty years of Telecom sales and marketing experience, he has held executive positions with Hewlett-Packard, Sprint and Ericsson.