The Road to SIP

If you are a fan of Tolkien's "The Lord of the Rings," you know that Aragorn was described by the words "Not all who wander are lost." Now, while that's perfectly fine for a ranger and the future king of Gondor, it's not fine for IT departments as they move their communications systems to SIP. To wander is to waste money, frustrate users, and perhaps lose a job or two. Instead, you want a plan, milestones to measure that plan, and acceptance criteria to ensure that you accomplished what you set out to do.

As a result of my many meetings with IT departments across the country, I've come up with a list of what I call "ask yourself" questions. These are questions that need to be asked and answered in order to determine what you are trying to accomplish and help uncover issues before they become problems.

While this may sound like an obvious question, I am often surprised when the answer comes back as "I am not really sure." Despite SIP being around for nearly two decades, there are too many people who aren't quite sure what it can do. This is where I help by refining the question into a series of queries.

Are you looking to add SIP applications? Perhaps you are upgrading to a voice mail system that only supports a SIP interface. SIP could also be the interface to a new conferencing server, contact center platform, or Interactive Voice Response (IVR) unit. Most traditional TDM-connected applications have made the move to SIP, and older, line-side T1 interfaces are a thing of the past.

Are you interested in replacing your TDM trunks with SIP? This is the starting point for many SIP conversions. In addition to lower costs, enterprises are excited about the robustness that SIP brings to their communications platforms.

Do you want to replace digital, analog, H.323, or proprietary IP (e.g. Nortel's UNIStim) telephones with new SIP stations? Not only is there value in upgrading traditional desk telephones, SIP clients have found homes on Windows and Apple PCs, tablets, and mobile devices. Frankly, mobile device clients are often reason enough to go to SIP.

What are your requirements for resiliency? Personally, I avoid single points of failure whenever possible. It makes no sense to spend a boatload of money on SIP servers, trunks, and endpoints only to have everything fall to pieces because the fan on a session border controller failed. Whenever possible, I look for active-active high availability (e.g. Avaya Session Manager), but realize that active-standby might be as good as it gets (i.e. every SBC on the market today).

Speaking of Session Manager, have you thought about a session management approach to SIP? SIP is a protocol, while session management is an architecture that orchestrates a network of SIP entities. Think of session management as the traffic cop for an otherwise unruly collection of SIP entities.

Have you considered separating SIP traffic by type? For instance, does it make sense to bring your contact center SIP trunks and knowledge worker SIP users into your network through the same SBC? There are scenarios where capacity and risk management drive you to separate ingress and egress points. This might extend to logical connections such as network regions and trunk groups. Keeping things separate allows an enterprise to selectively manage one SIP entity without affecting other SIP entities.

How do you want to deal with survivability? Are you willing to put all your eggs into the same SIP basket or do you want to keep some TDM around for emergencies? Think of it as a candle and a box of matches to survive a massive power loss.

How big do you want your SIP network to grow? It's important to think about scalability early in the planning process so you don't box (virtually and literally) yourself in due to the wrong choices for hardware, software, or architecture.

Have you considered cloud vs. owning? Cloud communications offers flexibility, innovation, and may be the best choice cost-wise. At the same time, an on-premises solution can still be the right choice for many enterprises. Do your homework, run your TCO calculations, and make an educated decision.

There are a number of requirements that don't necessarily fall into a specific category, but must be accounted for in your transition plan. For instance, ask yourself these questions:

• Do you use a lot of fax? Do you require the reliability of T.38 or is fax pass-through a viable option?
• What are your encryption requirements? Are there points where you need to decrypt SIP signaling and/or media in order to talk to components that don't have the ability to handle encryption? For example, you will need to decrypt all your SIP traffic to a SIP carrier.
• Do you need to transcode signaling or media? If so, will you do that in media cards or with an SBC?
• Have you started moving your enterprise to IPV6? Are there points where you need to convert to and from IPV4?
• Have you thought through your E-911 strategy? When you move to IP you need to ensure that if someone places a 911 call from a SIP station that the call is sent to the correct emergency responders.
• What sort of reporting do you need to deliver to your business units? Are you happy with basic Call Detail Recording (CDR) or do you require trunk utilization reports or departmental billing?
• How will you fix problems that arise? What sort of debugging tools do you need? How will your SIP components interface with your network management system?
• What does your system need to support in the way of security so you can sleep easy at night? Do you need historical reports? Do you require real-time alarms? Do you want your system to attempt to resolve security breaches as they occur?
• What requirements will you place on your SIP trunks service provider? Do you need to support more than one carrier at a time?

Whew!

As you can see, there are a number of things you need to think about before beginning any move to SIP. The good news is that nothing I presented is all that complicated. They are simply questions that need to be asked and for the most part the answers will be fairly easy to obtain. However, not asking will most likely lead to the wrong solution and some very unhappy users.

Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.

Follow Andrew Prokop on Twitter and LinkedIn!
@ajprokop
Andrew Prokop on LinkedIn