As might be expected for a series of blog posts about the Microsoft view of Unified Communications (UC), it is heavily biased towards Microsoft products but I wanted to take a brief look at another major player in the unified communications space – Cisco. It should be said that I have very limited experience of Cisco’s UC offerings (only as an end user of their IP telephony products) but it’s worth highlighting the differences between the Microsoft and Cisco approaches.
Microsoft and Cisco are partners, but they are also competitors. Some googling suggests that Cisco and Microsoft’s VoIP products can be integrated but not always without challenges (Aaron Tiensivu’s post on integrating Microsoft Exchange and Cisco CallManager is just one example of such a challenge) but it should be considered that they have come to UC from different directions.
Cisco are a networking company and they have approached UC as a networking problem for which there is a networking solution. On the other hand, Microsoft are a software company – they have looked at the overall user experience an attempted to engineer a software solution.
Whilst Cisco concentrates on providing a VoIP solution that offers Quality of Service (QoS) and has grown out of PBX technology, Microsoft relies on codecs that are tolerant of poor network conditions to deliver what they refer to as Quality of Experience (QoE). Those with far more experience than I have commented that the Microsoft approach is sensible for calls that are routed across the Internet (where there is no QoS) but less so in an enterprise environment and Ed Horley made a very valid observation that network links, particularly WAN links, tend to be under-provisioned. I have to say that using the SCCP/UCM solution at work provides fantastic call quality but I also find that the Cisco IP Phone (running SIP) on my desk at home provides a great experience too and, at a recent event, Microsoft even compared their solution with Skype, citing this as a well-known example of a software solution that provides good call quality over variable consumer Internet connections (something which I was surprised to find when I was using Skype for a video call between the UK and Australia recently).
Microsoft’s general recommendation is to let the software select an appropriate codec and Office Communicator will constantly assess the available bandwidth and select an appropriate codec, even switching codecs and/or tuning parameters as required during a call.
The main concern is with voice traffic saturating network bandwidth at the expense of data – that’s where QoS can be used effectively – to manage the network.
In the final post in this series, I’ll wrap things up with some notes from my own OCS implementation last year.