The feedback from my last post was great thank you. I also got a nice request from New Zealand to cover the perils of introducing VoIP on the LAN, since I gave so much coverage to implementing VoIP on a traditional LAN. Thank you, IT Manager in New Zealand, and here goes.
I’m going to start with a few definitions and clarifications (Warning: Technical Content).VoIP is made up of two components: Signalling/Control traffic and CODEC. The first establishes the call whilst the CODEC (or COder/DECoder) converts speech to digital media and vice-versa.
<start very technical bit – skip if you want to>
When I say VoIP, I mean SIP and G.711/G.729. Originally, VoIP meant either proprietary technology or a very loose standard called H.323. Proprietary technologies obviously meant that you needed a homogenous telephony environment (unless you implemented digital bridging with DPNSS or QSIG but that’s far deeper than I intend to go with this post); H.323 was designed to bring some conformity to VoIP but it was such a loose standard that vendors still often couldn’t interact. Tech example (thanks again Andrew): Cisco H.323 used short preamble for call establishment, Ericsson used long preamble and neither were configurable so they could never call each other.
SIP (for Session Initiated Protocol) is a signalling protocol; it’s job is to establish a call between point “a” and point “b”; it is deliberately rigid in order to prevent the issues with H.323. Virtually every IP-PABX supports SIP, and virtually every IP-PABX can talk SIP to every other IP.PABX. This solved the interoperability problem but created a new one: features. Most of the “cooler” features on PABXs (IP or otherwise) are somewhat proprietary to its vendor. SIP is the lowest common denominator, and designed to mimic the features of the carrier-facing end of a traditional digital PABX. This means that things like call-camping, conference calls, multi-party calls (beyond 3 parties for the purists) aren’t part of the protocol. Vendors had two ways of dealing with this: Server-based control (e.g. IPFX, Asterisk, etc.) or proprietary signalling (e.g. Mitel, Avaya, etc.). Both still use SIP, but they use other technology in order to extend beyond what SIP offers. My personal preference is for proprietary signalling as this doesn’t require a dependency on a File Server (that’s another topic). Both work very well though.
G.711 is a CODEC (or audio COMPANDing protocol for the purist COMPress/expAND protocol) which actually carries voice or “the media”. G.711 is not new, it’s been around as long as I have (i.e. since 1972) and has been ubiquitous for telephony since the introduction of Digital voice. Pretty much all IP (and digital for that matter) PABXs support G.711. G.711 utilises 64Kbps of bandwidth. G.729 is a compression technology designed to reduce the network load of G.711 ; it can drop the bandwidth cost down to 8Kbps but at a cost of voice quality; it’s still available but largely irrelevant in these days of fat WAN links.
<end very technical bit – read on>
When you choose to implement VoIP, there are two key considerations: Quality and Security; if you are implementing SIP carriage or connecting to a WAN, there are two more that are equally important: Routing and Bandwidth. I’m going to leave the challenges of VoIP over WANs to another post.
Quality of Service (QoS) is probably the biggest issue I have encountered with VoIP is QoS. The problem with VoIP is that in some ways it sounds too easy. A typical VoIP session (comprising of signalling + CODEC) is around 100Kbps (each vendor is slightly different here) which seems insignificant when you have a 100Mbps or GbE. Even 20 concurrent calls still only needs about 2Mbps! That thinking – along with network (or voice) engineers that just don’t understand VoIP (see my post http://dancingbear.com.au/2012/02/10/if-you-want-to-succeed-with-microsoft-lync-learn-telephony/ for more on this) – is why so many VoIP projects fail and to my mind is unforgivable since QoS on a LAN is a trivial task. I won’t go all technical again but to use an analogy: common Ethernet without QoS means that he who has the biggest hammer (i.e. demands the most bandwidth) wins the fight. A 200MB File Copy is a Jackhammer vs. the tack-hammer that a VoIP session wields. The file copy will completely lock a network segment for just a few seconds which may be irrelevant to most other programs but is an extremely long interruption for a VoIP call (acceptable delay for VoIP is only 150ms).
I’m only going to cover QoS for IP handsets in this post, which is what most people expect when they talk about commercial VoIP. QoS for soft-phones (including MS Lync, Skype or those supplied by various vendors) will be covered when I talk about VoIP over WAN since the requirements are similar.
Setting up QoS for IP handsets is generally quite straightforward; it mainly requires that you have the right network switches (i.e. switches that support 802.1q VLANs and 802.1p QoS). All that it really takes is to separate your voice and data traffic into different VLANs and to prioritise the Voice VLAN. That’s it, you’ve implemented VoIP successfully and you will have clear calls! Well, that’s not quite it, there are other things to configure like discovery protocols, dhcp and routing but they are either trivial (switchport voice vlan <x> on Cisco, equally straightforward for other switch vendors, routine (most data people can set up DHCP in their sleep) or both (unless you have a massive campus with thousands of nodes, LAN routing is trivial and routine).
The next consideration for VoIP is security. On older Digital PABXs, security was ensured through it being a closed system. Each handset connected directly to the PABX and unless you could get access to the wiring cabinets (IDFs and MDFs) or the carriage in the street, there was little you could do to listen in on a phone call. VoIP exists on a network, which can be accessed from virtually anywhere, and neither SIP nor G.711 support encryption. This makes VoIP far either to listen into (or snoop), given the right tools and technology which makes it vulnerable. This is where your choice of PABX vendor is very important, and is another reason why I endorse the use of proprietary signalling over server-based systems. Most of these systems support encryption of VoIP calls (generally using a very strong encryption like AES) which makes snooping virtually impossible. I give props to Mitel here for being the first vendor to have strong encryption turned on by default. If you care at all about the confidentiality of your voice traffic, then implementing a system that supports encryption is a must. A side-note here, Microsoft Lync (and its predecessor OCS) require encryption to be deployed, using certificates. This makes them a bit more complex to install but ensures that they are rock-solid secure (which gets my vote for a good architecture).
That’s all there really is to it. Get decent switches, set up VLANs and QoS and make sure you have the right security and your VoIP will be pretty much perfect. I realise this post is a bit shorter than typical for me but I’m a little tired tonight. I might revise or expand it in the future (as well as cover some of the other topics I’ve mentioned above) and of course I’m happy to field any questions anyone might have but that’s all for now.