SIP Trunks: A Year Gone BySIP Trunks: A Year Gone By

It's been over a year since I moved my office voice service over to all SIP trunks and said goodbye to an old era. Now I can report back on the new era experience and what it may mean for businesses and to those supporting the move over to SIP trunks.

Not long after cutting over I decided to move a back office line over to SIP too. My attitude is, better to put that money in my pocket than Verizon's. So the savings went up to about 43%. Originally when Verizon FIOS was initially deployed, customers complained that they could not just buy FIOS for Internet. We migrated out of Verizon voice provided via our FIOS service, and the bill stayed static until this year after receiving a notice from Verizon that our old FIOS pricing was no longer available. We upgraded our FIOS service to 15/5 Mbps.

We recently gave up the back office service and converted the number to a virtual DID with our provider. We carried a redundant service for a year and then we issued a disconnect request to the SIP provider and they acted like a phone company. The simple disconnect request was issued to them on February 2nd and it was completed on February 28th. After the upgrade and deletion of service, our monthly savings now rings in at 36%.

Any erosion of benefits would occur from too many issues and service-affecting outages that cause a company's calls to overflow to more expensive facilities or that results in loss of revenue directly attributed to the outage(s). I really can't say we've experienced this.

Voice traffic is not our top tier usage as far as bandwidth goes, and this as an admission softens the urgency of voice--at least you would think. As a business owner I’ll say, "voice is still crucial to our business because we are a service business." However you do look at voice you need to have a clear objective in mind, and ours was simply cost.

During the year, two problems did surface that we've experienced with our test trunks from 2009 and when our new service cutover in 2010. First is fear of talking for long durations--we conduct long support calls and even Webex sessions to a conference bridge and sometimes the call quality heads south after being on the call for extended periods, usually longer than 60 minutes. In only one instance did we have to hang up completely and reinitiate a new call.

What I discovered next is our IP-PBX "sensitivity" to the NOC's changes and maintenance during the off hours. An alarm light mapped to my phone shows loss of service during early morning hours. The NOC manager confirmed the dates/times from our IP-PBX log. Call this an anomaly. Only once during 2010 did we have a provider service-affecting issue and that was on December 31st and yes, I was in and working. The outage lasted just a few minutes. My guess is something had to be done during the day to allow the NOC crew to party at midnight. This year we had another outage again lasting minutes and it was the first one during business hours.

Other than those two issues, I haven't been playing Packet Man to trace packets. We did that in the past, with our buddies at ADTRAN proving the problem to the provider, but there was no accountability. Meaning, we have retail service, and how much of my time do I spend haggling over pennies when the provider came back with "we couldn’t match the call records." Still, rolling the truck for no dial tone vs. an insignificant number of calls with quality issues has a trade off. Rolling the truck costs money, and issues with copper lines could be equipment related. Minor issues with SIP trunks (call quality)--if they are an insignificant number--just don’t warrant a lot of attention. For SMBs this becomes an upfront question of, "Are you willing to tradeoff quality for cost?" I think this is relevant and unless customer expectations are geared for this, then there will be some backlash. How much time are vendors willing to spend chasing these issues for customers? Still, given the few incidents that were provider related, the tradeoff of quality for cost savings was worth the effort.When we upgraded our Verizon FIOS, I immediately did a bandwidth test and found that our upload speed remained the same. Our ADTRAN IAD (Netvanta 1335) is setup with VLAN 4 for Verizon FIOS and the interface has a fixed traffic-shaping rate formerly set at 2 Mbps (the old upload rate). Once I changed this to 5 Mbps, the bandwidth tests passed. That’s the only change required on our end to upgrade our FIOS Internet connection.

As for our ADTRAN 1335 (IAD) experience there's only one thing I'd change. Whenever we reboot our IAD, which hasn't been very often, our Voice Quality Monitoring (statistics) are dumped. Of course we can backup the data to an Excel file but it's just not the same as having accumulated statistics in one dashboard. We did setup a port in the ADTRAN IAD for port mirroring and a monitor port for a laptop to run Wire Shark should we run into issues. The easiest maintenance has been the ADTRAN gear--whereas a year or two ago I would have argued the IP-PBX would be the easier of the two to maintain.

Our Panasonic NCP1000 was upgraded to a Version 4 OS and that was a problem. I can say that our long day of troubleshooting, compounded by waiting on the phone for hours for support probably has changed my thinking too. The upgrade just wouldn't post to the system and we could not get the system back online with the former software because the DSP card failed. Perhaps the system and hardware were among the first installed, and there were possible manufacturing defects or quality issues. According to the Panasonic support engineer it was probably due to an electrical surge by turning the system on and off. (How much electrical protection does one require?) The good news is we had a spare DSP card on hand, not the same capabilities but ample for what we needed.

One other complaint is the inability to provide individual call appearances for each call, meaning--make each call show as a line appearance. Because SIP uses bandwidth there's no square system or line appearances for each line and SIP trunks are virtual, since you buy concurrent call sessions (CCS) that you configure/contract in whatever increments you can support with available resources. After getting pressured by the "community" we settled on using Call Park. This meant programming two buttons with a Call Park and a Get Park (retrieve the call) button and then printing new desi's for the phones. Once a SIP call is answered at an extension, placing it on hold puts the call on hold at the extension only, and getting it somewhere else is by transfer. In some cases we transferred the calls but couldn’t get there fast enough before the calls bounced into voice mail. So I may be in the equipment room answering a call and then needing to get it to my office. Now this may sound trite and it isn't because unless you have enough buttons on your phones, then getting a Call Park and Get Park buttons may not be options. Traditional telephony vendors try to outsell the other guy by selling cheaper phones (less buttons = less real estate = lower bid). The "work around" is to tell the users to use dial codes to park calls and then retrieve them with another dial code, and even then it becomes a disruption to smooth call handling.

So in welcoming a new era of telecommunications I wonder, what next? When our contract expires in two years (no we will not let it "auto renew") my inclination is to explore Verizon’s offering so we might yield answers to my questions. I would like to still experience Verizon's SIP trunks and any beneficial cellular packages and enhanced features. Two years is a long way off and what I want specifically added for our ideal SIP trunks:

* Network voice mail/auto attendant with basic reporting capability (My bet is it is cheaper than the electricity cost to run our system)

* The ability to transfer calls to cell phones without tying up two concurrent call sessions for the call

Whether or not this happens through a provider, it's interesting that today we pay the most for cellular services, with bandwidth costs being second and voice services (SIP trunks) being third.