Don’t Slip Up with SIP

When it comes to implementing SIP, which I still consider a relatively new service — and one that is considerably more complex than the PRI or T-1 connections it typically replaces — working with a consultant who has ample experience with SIP trunking is critical. One such expert is SCTC consultant Melissa Swartz, and that’s why her recent two-part UCStrategies.com series on implementing SIP caught my eye.

In Working Order
The first implementation challenge you’ll likely face is getting the service to work. SIP depends on a relatively complex signaling protocol, one that allows for a lot of variations in implementation. Simply uttering the three letters “S-I-P” in no way guarantees that everything is going to pop up and work correctly.

As a first step, Melissa recommends confirming that your session border controller (SBC) is certified to work with the carrier you will be using for your SIP trunks, and that the carrier has included the cost of the SBC in its services proposal (see her post, “Pitfalls to Avoid When Implementing SIP Trunking – Part 1“). In addition, make sure the carrier gives you the specific SBC settings or at least points you to a webpage where you can get them. You’re likely implementing SIP with the goal of reducing your telecom costs, but nobody is going to save money on a service that doesn’t work.

Also on the cost side, you need to make sure you understand all of the elements in the pricing. SIP trunking service providers typically bill for the number of simultaneous conversations (sometimes called “sims”) the interface will support — one of the advantages of SIP is that you can buy the exact number of trunks you need, rather than buying in bunches of 23 or 24 as you do with traditional PRIs or T-1s. Most of the service providers charge for both local and long-distance calls, though many include a specified number of long-distance minutes with each sim. You’ll also see differences in pricing for back-up sims.

Melissa identified one pricing gotcha she found in a carrier contract that I hadn’t previously encountered — a penalty charge for excessive short calls. The carrier had apparently included this little surprise to protect itself from outbound telemarketers. Such companies, as you might imagine, get a very high percentage of disconnects early in calls (like as soon as the called party realizes a telemarketer is on the line).

Among other potential pitfalls Melissa identifies are not having hardware with an interface that matches what the vendor provides or not anticipating the lead time involved in getting a new MPLS connection if that is what the SIP trunks are going to ride on. And if you can’t get your numbers ported correctly, you can be blowing the better part of your weekend on that install.

Service Gotchas
In the second part of the series, Melissa digs into some of the more subtle though equally service -impeding gotchas. First, and the one that could lead to the biggest legal liability, is E911 support. She notes that some of her SIP clients keep one analog POTS line in service just for 911.

Fax can be headache — one that just doesn’t seem to go away — with SIP, too. So if you’ve got a fax requirement you may have to limit the transmission rate to 9,600 bits per second or ensure the carrier is using G.711 (i.e., 64-Kbps PCM) to encode the signal. Apparently the T.38 standard for fax over IP is off the table.

Further, Melissa has found that the carriers do not implement features consistently. SIP Refer, or trunk-to-trunk transfer in traditional telephony, is one example. In traditional telephony parlance, trunk-to-trunk transfer is the term for transferring an incoming call to an outside party, possibly a user’s cell phone. That transferred call usually winds up tying up two trunks as long as it persists (a configuration we also call “hairpinning”), and some SIP carriers don’t support it or do so only upon request.

Caller ID, either incoming or outgoing, can also be a touchy issue and may be lost on some calls or the wrong number could wind up being sent. Failover routines, too, can be fraught with difficulty. First, you need to know what event is going to trigger the failover. In one test she described, service did not failover to the backup when the PBX and data network were taken out of service. It turned out this company’s carrier only recognized an SBC failure as the trigger event for failover.

With SIP trunks, getting down into the details, knowing fully what you are buying, and understanding the effort needed to cover all of your bases is really important. Finally, testing of every possible scenario to see exactly how the service and the equipment are going to respond is the only way to really know what your experience is really going to be like.

While I don’t get involved these sorts of details on a daily basis, it is important for all of us, regardless of our level in the organization, to be at least aware of the challenges we face in dealing with any new technology. Inevitably the technologies we deal with are complex, and that complexity needs to be managed. It’s great to have people like Melissa who have been “down in the trenches,” worked through the problems, and are now able to give the rest of us a head-start on putting these things to work.

For Melissa’s No Jitter posts on this subject, see:

• SIP Trunking: Not a Simple Replacement
• SIP Trunking: Not a Simple Replacement — Part 2