There's no doubt about it: IP Centrex is gaining steam, and quickly. With a comparatively miniscule initial investment to traditional telephony platform offerings, the market may be shifting ever-so-slightly to the "switch in the cloud."
Your voice infrastructure, local or remote, operating over a LAN or WAN, is only as good as its weakest link. Every hop between you and your ITSP, or IP Centrex host, will come under performance scrutiny at one point or another. To illistrate, a 10mb hub sitting at your LAN telephony backbone would cause a major traffic jam, therefore so would WAN packet loss, or mis-proritization or cateorizing of QoS information.
There's a lot to consider when looking at an IP Centrex solution. Here too do we see the "chicken-or-egg" problem. For SMBs, where IP Centrex may be most attractive financially, do we see the weakest and non-redunant WANs. However, in large organizations where upstream connectivity is rock-solid, IP centrex is not as attractive or cost-effective in comparison to an in-house telephony operation.
Let's review some of the key considerations when thinking about an IP-Centrex proposal. Most people here the acroynms 'QoS' and 'VoIP' together, and assume a good working relationship between the two. Now, consider that media prioritization is still a hot-button legal issue for ISPs and peering agreements, and in fact, QoS applied do de-prioritize RTP traffic could have cause a significant and deadly blow to your IP Centrex reliance. Also, it's important to keep in mind that ISP policies, and more importantly, peering policies can change overnight without much being said to the customers.
In addition to the QoS concerns, overall reliability of the provider is of another concern. SLAs and other agreements and disaster recovery plans need to be in place to ensure very limited, or no downtime. Users can stand being without email for an hour, but take a way their dialtone for even 15 minutes, and major frusteration will potentially occur.
In my honest opinion, before any IP Centrex rollout occurs, a large amount of testing and collaboration with the ITSP needs to occur. Establish and maintain constant contact with all parties that maintain the links between your desk, and your ITSP. Run disaster recovery scenarios to ensure that you have covered every potential situation and liability.
IP Centrex is a great thing, and in fact, I'm personally very dependent on it for conducting day-to-day business. However, this dependence has evolved out of a carefully-executed plan that has taken many weeks and many months to test and implement. With that, IP trunking and Centrex services can relieve an incredible burden from your small or large organization's telecom responsibilities.
How have you implemented IP Centrex successfully? What has worked, and what has not?
The Leader in Network Knowledge
