Adding VoIP to your network – some things you need to know

Hi again,

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.

About these ads

Microsoft Lync – Get used to it, get used to loving it because if you are in business, you will be running it soon

Unified Communications has been a passion of mine for over a decade. I left a senior position at Australia’s largest carrier in order to become a minor partner in what was to become one of Australia’s first truly UC-focussed businesses. Flash forward to around 2004 when we got involved in a tender for the complete Voice and Data fit-out of the NSW Institute of Sports (where the likes of Ian Thorpe and Louise Sauvage trained) who were building their new purpose-designed facilities at Sydney Olympic Park. Up to that point, I had primarily relied on voice-vendor supplied UC solutions so it was with some trepidation that I learned that they were really keen on this relatively new Microsoft UC solution called “Live Communication Server”. Whilst a huge fan of Microsoft in general – Windows Server (in all its iterations since 3.1 beta) and MS Messaging (since MS-Mail v1.3) had been my bread and butter throughout the 90s but every encounter I had up to that point of any sort of Voice solution on MS Servers had ranged from terrible to catastrophic. That was until I met Oscar Trimboli (he is the guru of all things Microsoft business related in Australia – look him up!) who was the then head of the local MS-UC business and he gave me a deep-dive into the product and helped me see how it would interact with our chosen Voice and Networking platforms.

Still, we were up against 6 or 7 other tender respondents all of whom represented far more vendor-centric and “mature” solutions than what we proposed. It turns out we won the tender and ended up deploying the first ever fully voice-integrated MS UC solution in Australia. It also made me a complete convert to Microsoft UC (and UM since the release of Exchange 2007), which has been one of my  favorite technologies ever since. I spent the next several years banging out LCS, OCS and OCS R2 solutions for organisations large and small but always with Microsoft as the product supplicant to someone else’s VoIP.

Suddenly we have Microsoft Lync, where Microsoft decided to change the game. Where the previous UC products – whilst amazingly versatile – felt somewhat raw and unfinished, Lync was released as a smoothly polished total package. Coming on the  heels of MS Exchange 2010 – which includes a more powerful and veratile Voicemail engine than most commercial IP PABX vendors offer (at a fraction of their price) and Microsoft was suddenly a forefront player (pardon the pun) in the voice game. Lync is secure – far more secure than the vast majority of IP PABXs which still transmit voice without encryption – straightforward to deploy, highly reliable and virtually infinitely scalable. Unlike previous versions, there are now powerful Receptionist, Call Recording and Contact Center products integrated with (or available for) it. What’s more – and this is certainly a strategic move on Microsoft’s part – they put the focus on a person’s identity as being most important rather than something as nebulous as their phone number (more on this later). Having recently released well-featured client software for most current SmartPhones and the first half of their establishment is now complete.

The second half is far more subtle and far-reaching. Being “yesterday’s news”, a lot of people have already forgotten that Microsoft purchased Skype last year and that the transfer of ownership was completed in November last year. Think about that for a moment…Microsoft – the organisation whose products are used by the vast bulk of businesses globally now owns possibly the world’s best known pure IP Telephony network with points of presence in virtually every major country (and certainly every major business country). They also now own perhaps the most robust and clear voice CODEC (COder/DECoder) in the world (Cisco was licensing Skype’s CODEC for their Teleworker product for years, if they are still doing so I hope they are being very nice to their friends at MS) and a pretty decent multi-person Video Conferencing engine (one of Microsoft’s few weaknesses in UC was the “one-to-many” model of Live Meeting was always more suited to lectures and presentations than to multi-party collaborative meetings).

So now the world’s largest software company  – who has been pouring development dollars into their UC and UM product suites – is one of the world’s largest VoIP-based voice carriers. From my previous post, you already know my predictions that virtually every business will be moving to VoIP over the next few years (not really a prediction since its mostly occurred already) but what I didn’t mention is that most Voice Carriers are starting to offer VoIP trunks (technically called SIP trunks) in lieu of traditional digital trunks (they actually been doing this for years since SIP exchanges are far cheaper than Digital exchanges but they’ve been “black-box” converting back to Digital on the customer premises before presenting it to the PABX) which means that customers can get by without any traditional Voice links and run everything via their data links. A large part of this has been in necessary response to a number of IP PABX vendors certifying their equipment for use with pure SIP carriers (such as MyNetPhone or Skype). Microsoft now has a full-blown pure-software UC system which many organisations already own the licenses to use (through their MS-Select/EA/SBS agreements) along with one of the most trusted and least costly carriage services in the world (here in Australia, it costs only about $72 per year for unlimited land-line calls nationally or about double that for unlimited global land-line calls; most carriers charge that much per month!). How long will it be before they start bundling in carriage as part of those aforementioned Select/EA/SBS agreements? How many businesses will turn their backs on having their Telephony costs slashed to a fraction of their current costs?

What about mobiles? Skype costs a fortune to connect to mobiles! Your whole theory falls apart since more and more people are now using mobiles as their primary means of telephony! Sorry guys, this includes mobiles as well.

The advent of low-cost, pervasive, reliable, high-speed, low-latency data carriage on cellular devices has made the use of VoIP on mobile devices not only practical but in many uses preferable to traditional cellular connectivity. The ability to have a single “identity” (there’s that word again) that rings regardless of whether they are near their PC/Laptop or mobile means that they are always contactable on first attempt and that – if the other party is also a Skype (or similar) subscriber – there is no “voice” carriage cost either. Current data plans are such that a user would have to make an enormous amount of calls before they start eating into a typical data quota.

I’ve mentioned the word “identity” a few times and that was deliberate. The concept of ownership of a person’s “corporate” identity is becoming increasingly a matter of concern for businesses. In the past, you got a job and you were given an email address, a desk number and issued with a company mobile phone (with a company SIM inside it). These days, most companies allow (and are more or less required in order to maintain staff morale) staff members to bring their own device (almost always a Smart Phone in the business world). This raises the issue of the SIM card since it creates a very grey legal area of who owns the number and who pays for the calls and data (since the staff member will certainly make personal use of it). To get past this, the most accepted strategy is to provide the staff member with an allowance to go towards their phone and its call/data costs and leave it at that. Problems with this strategy arise when that staff member leaves the company as they are taking with them what is no doubt the primary way that their clients have been making contact with them which in turn helps the company’s clients follow them to their next place of employ.

By using Identity-driven communications, this problem goes away. The user is still issued with an email address, desk phone number and a mobile allowance but now they are forbidden by company policy to hand out their personal mobile number to clients; and it has no appearance on any of their business literature. Their clients are still able to reach them via their desk number as this will simultaneously ring via VoIP; and it will further be policy for them to make all business calls via VoIP from their cellular device. This means that the company in question now completely controls their staff members’ business identities through every means of business communication. This also means that they can audit and – if necessary (and with all due probity) – record their employee’s business calls. Of course this also allows all this wealth of information to be captured into the business’ CRM system (wait, doesn’t Microsoft have one of those too…?).

For these reasons and more, I believe that many businesses will find the move to including their carriage and carriage management through to MS Lync as the center of their communications systems rather than on its periphery to be irresistible.