Over the course of the last few weeks, I've spent some time doing some research into Microsoft's Office Communications Server (OCS 2007) product.
OCS is a
Unified Communications (UC) product that integrates with Microsoft applications. It provides voice, presence, web/audio/video conferencing and integration with messaging systems. OCS can also integrate with PBXs, both TDM and IP-PBX. The introduction of OCS in the fall of 2007 created a lot of market hype and in my view, confusion. Microsoft marketing did a great job of capturing media attention and giving the impression that OCS was a revolutionary new communications technology and that enterprise communications, from that point forward, would be transformed forever. So effective was the marketing campaign, that some large organizations halted their VoIP migration planning in order to consider how OCS might alter their strategy.
The intent of this article and more that will follow, is to separate hype from reality so that you can make informed decisions about UC and how OCS should fit into your UC strategy. This first in this series of OCS articles discusses the topics of Call Admission Control (CAC) and Quality of Service (QoS).
Call Admission Control and Quality of Service – Short Tutorial
In the context of telephony, CAC refers to a telephony system's ability to decide whether a call request should be allowed or not. In the world of IP Telephony, VoIP is the common method of transporting voice. Analogue voice is converted to a digital from, encapsulated in IP packets, and then transported across a data network. A data network is made of a series of network links all of which have limits with respect to the amount of data they can carry at any give time. When a network link is oversubscribed, devices responsible for sending the data across the links will randomly drop data, which is what they are designed to do.
Quality of Service (QoS) mechanisms can be designed into networks to ensure that during periods of congestion, certain types of data will get priority over others. In IP Telephony implementations, voice and telephony-signaling data packets are marked with a priority label that informs routers that, in the event of congestion, that they should give priority to the telephony packets. However, if the amount of prioritized traffic exceeds a links capacity, then the router has no choice but to randomly drop even this high priority traffic. If the high priority traffic is telephone conversations then the quality of all calls will be affected, not just the call that exceeded the links capacity. This is where CAC steps in to avoid this situation.
CAC approaches vary but in all cases it consists of the system not allowing more calls than a resource can support. The most robust method will, in real-time, discover the available bandwidth available across the entire path of a proposed new call, then decide if the call should be allowed, and reserve the resource for the duration of the call. If insufficient resources are available the system can refuse the call or send the call across a backup path (like a PSTN gateway). More basic systems require a human to configure the system in advance with the maximum number of calls that should be allowed across a particular network path regardless of how much of the resource is available at the time of the call request.
Some of the arguments that I've heard, usually from vendors that don't support CAC, is that a network can be engineered in advance so that the over subscription problem never occurs (design for worst case). For a number of reasons, that approach is not practical in large enterprise environments. For one thing, bandwidth is not free. Second large IP networks are often designed so that automatic rerouting can occur during failures. In many instances the backup links will have less bandwidth than the primary links. So, a system designed to allow a certain number of calls based on a primary link's bandwidth could over subscribe a backup link.
OCS Support for QoS and CAC While OCS does support marking voice payload packets for priority network treatment (DiffServ through DSCP) that functionality is not enabled by default. OCS has no Call Admission Control functionality. Microsoft claims that QoS and CAC are not required to ensure voice quality in an OCS environment. Microsoft uses a proprietary CODEC called RTAudio. The RTAudio codec is designed to detect network congestion or quality issues and to modify its bandwidth requirement accordingly. Also, the CODEC has an algorithm that allows it to send multiple duplicate packets to increase the probability that packets will arrive at their destination when network problems are encountered. As a result Microsoft argues that QoS and CAC are not required.
In my view, that logic is fine for Internet Telephony solutions. That is, if you’re transporting voice traffic across the Internet, then a CODEC that modifies its data usage and sends multiple copies of packets, makes sense. When transporting VoIP across the Internet, QoS markings will be ignored. In addition, there is no practical way of detecting in advance of call setup whether sufficient bandwidth is available along the entire call path. Even if one could determine that in advance, there is no way of ensuring that the desirable network conditions will persist for the duration of the call. And, if the fact that your throwing more packets at the problem, adversely affects other Internet traffic, who cares? One has little or no control of network conditions of random source and destination paths across the Internet. So it makes sense to use whatever means are at your disposal to ensure that your traffic gets through, and there is no point in employing mechanisms that won't make any difference.
But that logic does not fly in enterprise class telephony environments. First, while it is true that the RTAudio CODEC adjusts its bandwidth usage based on network conditions, it does not accomplish this instantaneously and therefore voice quality may be affected during the transition period since the algorithm starts with the assumption that there are no network issues. Secondly, while the CODEC can reduce its bandwidth usage, it does not reduce it to zero. When not using redundancy, the CODEC can reduce its consumption from 45Kb/s to 15Kb/s. Additionally, redundancy (sending multiple packet copies) may exacerbate a network congestion issue and potentially adversely affect competing enterprise traffic.
Additionally, what if WAN link is heavily congested? Should the system continue to process all requests across that link, even if the RTAudio CODEC is not able to compensate sufficiently to ensure adequate quality? With no CAC capability, this is exactly what OCS would do in that situation. Also, what if the business requirements dictate that a high fidelity CODEC is mandatory? The OCS approach would not be able to meet this requirement under congested network conditions. A properly engineered QoS solution with associated CAC however, could.
Conclusion An IP Telephony solution, including OCS, when deployed in a typical large enterprise environment, cannot practically guarantee consistent voice quality without incorporating QoS and CAC mechanisms, end of story.
Notice, I did qualify the above statement with the word “practically”. It’s possible to engineer almost any technology deployment, no matter how deficient the technology may be, if one is free to ignore practical constraints such as business requirements, cost, manageability and scalability.
Rick McCharlesUnified Communications Practice Principal
RIC Services, Toronto, Ontario, Canada
Stumble It!
