If you haven’t heard yet, there’s a new kid on the block as it relates to connecting dial tone to your phone switch. Nearly all of the traditional service providers (and even some new ones) have come up with some sort of SIP offering for PSTN connectivity. However, seeing as the technology is still in an embryonic stage when compared to its ISDN forefathers, each service provider seems to have their own little tweaks to SIP delivery.

Now, not every PBX or phone switch out there is ready to support SIP dial tone…which, in my opinion, should be the second thing you investigate. The first and most important question to ask is “What does SIP offer to my company that traditional TDM based dial tone does not?”

To illustrate this important point, let’s go back a few years – the birth of VoIP. Back in those days, a little more than a decade ago now, Cisco led the charge in converging TDM based voice technologies onto a packetized, often IP driven, data networks. In doing so, we all became ever so aware of some of the risks and more importantly the risk mitigation techniques needed to be employed to make the conversion plausible. While we got the benefit of toll bypass, we picked up the responsibility of assuring an even level of service to RTP streams across our wide area network – quality of service (QoS). While we assumed all the advantages of a single PBX instance for an entire enterprise, we acquired the responsibility for providing local call processing for a remote site when a network failure occurs.
Some had to learn these lessons through hard knocks. So, my question is to you, how will you learn from history and avoid being doomed to repeat it? I have a few suggestions…

1. Start with a solid business case (or lack thereof) for a SIP rollout. From my position, I see two strong cases:

   a. Cost Savings – I have a few clients who have multiple remote sites that require PRIs for functional reasons, but may not have the usage requirements to support 23 bearer channels. A regional bank is probably the best illustration of this. While a bank branch may need DID, DNIS, addressable CLID functionality, they typically will have fewer than 3 or 4 concurrent calls during any period of the work day. So in this case, if we can bring those 3 or 4 talk paths onto a data circuit and relieve the cost of the PRI loop, we can save some money.

   b. Disaster Recovery – This is a big one. When you have a site or a remote PBX go down, you have few options to get those numbers re-routed to another site and avoid the “All circuits are busy” message being played repeatedly to your customers. At best, you can call your service provider and request an emergency call forward on a few numbers which typically gets put in place within a few hours – just in time for your circuit to come back online…wash, rinse, repeat. With SIP, most carriers allow for backup IP addressing for where a call is delivered to your network. This gives us the flexibility to offer at least one other point of entry to the network for those numbers…without having to call a soul.

2. TEST, TEST, TEST and then TEST some more. Seeing as most of these service offerings come from providers who are already offering you data services today, it stands to reason that you could have a few test numbers lit up and use those to test. Some key items you will want to watch out for – voice quality, DTMF exchange (call into an IVR), call forwarding and outbound CLID preservation. Once you think everything is working fine, port a few DIDs for a few users. Nothing says you need to cut an entire site or even a heavily used number the first time.
3. Pick a good partner. SIP cutovers don’t always go as smoothly as you might like. You’ll want to have a partner who has done a number of these cuts before and is adamant about having a solid reversion plan. If you’re having trouble finding one, give me a call…I should have a recommendation or two.