Standardization and Flexibility
Just like Henry Ford grew the automobile business based upon the obvious concept of standardization, the VoIP industry gained its recent focus and popularity based upon the same ideals. Gone are the days of having to select and architect a solution based upon the supported protocols of one vendor and become locked in. The two major signaling protocols you will see today, H.323 and SIP are the largest players, with H.323 starting to lag behind as SIP gains in popularity and support, more compliant vendors, and continued enhanced to support more media streams and tighter device integration that up until recently has been what was keeping H.323 ahead in the game. Keeping in mind that H.323 is still the more mature technology, currently it is holding its ground in the carrier space and is used quite extensively as a trunk side protocol. This has allowed SIP to comfortably gain foothold in the enterprise space as a local carrier style protocol that is simpler to implement, troubleshoot, and extend with new features as needed. It is clear that for a system to be considered future proof it has to support the currently prevalent standards but also allow ‘plug ability' and offer support for emerging standards, or alterations to the existing standards as well.
Unless you are starting from scratch you are most likely attempting to integrate a VoIP option into your existing infrastructure as part of a phased deployment strategy. The current list of options to accomplish this is growing longer and longer every day, and that has many benefits for the consumer with regards to architecture, cost, interoperability options, and the quicker movement to tighter standards compliance between vendors. There is no longer a need to consider the move to VoIP to be an all or nothing deal with the introduction of gateway devices that allow you to leverage your current investment in older TDM based equipment and enhance it with the newer IP based messaging solutions. Doing this allows you to add new devices to the newer IP network while maintaining a rich level of integration with the legacy TDM equipment until it lives out its natural (and still depreciable) life span.
Read more below
As with everything today, security is a huge consideration when you start to think about moving to VoIP. If it is not something that you have already though about, or your vendor has not discussed it deeply with you then I urge you to stop reading this right now, go to your vendor and ASK how secure your current VoIP implementation (or the one you are planning to install) is. Go on, ask them… I will wait…
So you are back? How did that go? Good I hope.
Security is so critical in today's business market, but because people have felt so safe in the past using TDM voice infrastructures where ‘tapping' meant actually making a physical connection to the ‘wires', the thought of security quite often eludes people when you starting the talk about VoIP. It is so easy to fire up a copy of Wireshark on your network, collect some packets, and use the tools built right into the GUI to listen to VoIP conversations. So, what do you do? The answer is simple. You turn on encryption and ensure that every device you use within in your IP infrastructure involved in the call supports the encryption scheme that you pick. Keep in mind that while encryption is good, it does add CPU load to your devices, can cause higher network utilization because the packets can get larger, and can add complexity to any troubleshooting efforts, but you should NOT implement any VoIP system without taking security into consideration. One fine option that I have used is to consider your internal network to be secure and just encrypt the calls that pass via IP between external parties (over your IP based trunks if you use them) or between all your company locations using the public IP network. It's my feeling that as long as you keep your internal IP infrastructure secure (IE: tight controls on who can enter your IT area, and you are using switches rather than hubs), bothering to encrypt internal IP connections is not always needed because in a properly configured environment you will not be able to capture VoIP data other than what is directed to you. If you are using hubs then all bets are off of course. That is a subject for another article.
As with most other technologies, part of your purchasing and deployment planning MUST be to take the support model into consideration. Don't just assume that your existing vendor that supports your current internet connection to the external world is going to be there if you have IP trunk problems, understand what terminology like QoS, jitter, and other VoIP lingo means, or even how to correct them if problems occur. As when introducing any new technology you need to have a sit-down with everyone involved in the proposed value chain and establish an understanding of expectations, possible support needs, costs, and schedules. You may find out that your provider is by default blocking the native ports that the typical VoIP protocols require simply because they are not used to requiring them to be open for other clients. If you are ready to move to IP for your voice communications just understand that while you may have been willing to put up with slowness in the afternoons when you tried to use the web to order your dinner so you could pick it up on the way home, a slow data connection can wreak havoc with voice quality and the ability to establish a call. You may need to consider a separate IP connection just dedicated to voice, and in fact you may need to start considering redundant connections using two different providers for your voice if you have not already done so for your data. Additionally, ensure that your vendor has the proper debugging tools in place, knows how to use them, and is willing to offer training to your staff, or that you are willing to use third parties to get them trained, so that they can be used to keep the system running in top condition. Remember that voice communication is still considered a top priority in today's business world and loosing that, even for a few hours, can make a customer start looking for someone to replace you as a vendor.
Many people today are used to just using the phone to talk, or maybe send faxes, but once the move to IP is made the benefits will start to bring on questions about other methods of application integration, and additional ways to leverage the new communications system. One thing that you should always consider on any new system, not just VoIP, are ways that you can utilize it going forward for things other than just your current needs. A car would not be much use if you could only drive it back and forth to work would it? The same goes for your telephony solution. Right from the start you should consider investigating the extension areas of all the solutions you look at and at least gain an understanding of the features and benefits that each system may or may not offer. For example, it could be very disappointing to get a system all in place and six months latter determine that you still need to add a bank of analog trunk lines to and receive faxes because your solution did not include the ability for Fax over IP (FoIP) codecs. Making blanket assumptions like ‘just because traditional faxes use our existing voice lines the VoIP system should also do fax' can lead to some very tense moments across a boardroom table. Also consider integration with other areas like Instant Messaging (IM) and application integration such as the ability to build basic Interactive Voice Response (IVR) menus (IE: ‘To talk to support, please press 1, to talk to sales, please press 2,…) into the system and create simple auto attendant applications. These simple features can help add some great value that may not have been considered previously, and allow you to recoup the costs of a VoIP implementation over a shorter timeline than previously anticipated. Areas like this can allow you to bring systems together under one area and thus cut down the size of your external vendor list.