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 an IT department 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 you need to ask in order to determine what you are trying to accomplish and help uncover issues along the way.
What are you trying to do with SIP?
Are you looking to add SIP applications? Perhaps you are upgrading to a voicemail system that only supports a SIP interface. What do you need to do to your PBX to support this new application?
Are you interested in replacing your TDM trunks with SIP? Are these trunks used to tie two or more communications systems together or are do you want to bring in carrier SIP trunks?
Do you want to replace digital, analog, or H.323 telephones with new SIP stations? Are you looking to add SIP clients to your mobile devices?
What sort of configuration are you trying to build?
What are your requirements for resiliency? Can you afford single points of failure? Do you need hot failover or is warm standby good enough?
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.
Have you considered separating different types of SIP traffic? For instance, are you willing to bring your SIP trunks and SIP users into your network through the same SBC? There are situations where capacity and risk management force you to create separate ingress and egress points.
How do you want to deal with survivability? Are you willing to put all your eggs into the SIP basket or do you want to keep some TDM around for emergency situations?
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 yourself in due to the wrong choices of hardware or architecture.
Have you considered cloud vs. on premise? Cloud communications offers flexibility, innovation, and may be the best choice cost-wise.
Do you have special needs?
Do you use a lot of fax? Have you determined if you require 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 or media in order to talk to components that don’t have the ability to handle encryption?
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 require? 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?
As you can see, there are a number of things that you need to think about before you even begin moving 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.