© Copyright 2009. Yankee Group Research, Inc. All rights reserved.
Network Considerations for Microsoft OCS Deployments
by Phil Hochmuth and Zeus Kerravala | November 2009
This custom publication has been sponsored by Microsoft.
Enterprises that are adopting unified communications (UC) platforms such as Microsoft Office Communication Server (OCS) must carefully
consider and plan how UC will affect their LAN and WAN infrastructures, as well as how their networks may either hinder or improve the
performance of a UC solution. Everything from bandwidth considerations, to firewall topology, to end-user habits and experiences must be
taken into consideration. If done correctly, enterprises can realize great productivity gains with new levels of collaboration, both internally and
with external parties. Reduction of WAN and LAN infrastructure, built to maximum capacity in support of past IP telephony or voice/data
convergence efforts, can also reduce costs and lessen management complexity in the long run.
This report examines four case studies of enterprises that have deployed Microsoft OCS Enterprise Voice and evaluates the cost-saving
opportunities, best practices and challenges around each organization’s deployment.
Executive Summary
Table of Contents
UC as a Strategic Collaboration/Communications Platform vs. PBX Replacement I. 2
Case Studies of OCS Deployments II. 2
OCS and Your Network: Recommendations and Best Practices III. 8
OCS Costs and Benefits: A Breakdown of Potential Savings 1IV. 1
Conclusions 1V. 2
OCS Enterprise Voice Deployment FAQs 1VI. 3
© Copyright 2009. Yankee Group Research, Inc. All rights reserved.2
Network Considerations for Microsoft OCS Deployments
UC as a Strategic Collaboration/I. Communications Platform vs. PBX Replacement
The adoption of enterprise IP telephony systems throughout
the 2000s led to wide-scale replacement of PBX systems with IP
PBXs and phones. During this transition, enterprise architectures
were modified to basically re-create circuit-switched TDM voice
infrastructures on top of IP networks. Enterprises saw cost
savings from IP/TDM network convergence and management
consolidation in return for large and often costly upgrades in LAN
and WAN infrastructure to support vendor requirements such
as QoS and traffic segmentation. Traditional IP telephony systems
do not provide deep integration of telephony with desktop and
line-of-business applications, do not incorporate the concepts of
identity and presence, and may have challenges providing a quality
experience on networks where the enterprise does not have end-
to-end control (i.e., the Internet). This latter limitation is becoming
increasingly important as enterprise workforces become more
dispersed and mobile.
Microsoft has taken a different approach, providing IP telephony
functionality as part of an integrated communications software
suite based on the concepts of identity and presence. Over the
past decade, the company has built upon its investments, from the
earlier days of Computer/Telephony Integration (CTI) to H.323
NetMeeting conferencing, messaging and video, and culminating in
its current OCS platform.
Microsoft OCS is a UC platform based on Microsoft Windows
server technology that incorporates enterprise telephony and
messaging along with presence management. The client technology
consists of Microsoft Office Communicator (for IM, voice, video and
presence) running on both PCs and dedicated telephony endpoints
from third-party partners. OCS uses a back-end server technology
based on industry standards, such as the Session Initiation Protocol
(SIP), as well as advanced media capabilities on endpoints using both
standard codecs and a codec developed and licensed by Microsoft.
This Yankee Group report examines the experiences of four
large organizations that have deployed Microsoft OCS, taking into
account their drivers for adopting the technology, their approach to
the deployment, and how they overcame obstacles and issues along
the way—particularly from a network-centric and voice-quality
troubleshooting point of view. The common thread—and the most
important trend—among these examples is that these enterprises
are deploying UC and OCS as more of an application, independent
of the network layer, as opposed to a service tied intrinsically to a
Layer 2/3 infrastructure or to proprietary, purpose-built endpoints.
The second half of this report breaks down best practices in
network-related aspects of OCS deployments, based on lessons
learned from the enterprises profiled in the case studies. At the
end, a TCO guide and FAQ section serve as handy references to
help enterprises and partners know what to expect when rolling
out this technology.
Case Studies of OCS DeploymentsII.
Many enterprise UC platforms begin as pure IP telephony solutions,
with features such as unified messaging (voice/e-mail), presence
and IM/chat added incrementally though the lifecycles of various
products. Microsoft OCS differs from other solutions in that it
had no previous IP telephony platform as its base. Components
of the OCS architecture came out of its predecessor, Live
Communications Server (LCS), a solution designed to deliver
all channels of UC in a single integrated package. Each UC tool
included was considered an equally important piece to the entire
solution, rather than just a feature added over time. While OCS
was initially criticized as lacking enterprise-grade telephony features
and resilience, the 2007 R2 release of the product introduced these
capabilities and positioned OCS as an option to replace incumbent
IP telephony solutions within an enterprise.
The following four case studies chronicle how companies across
various industries are deploying, or plan to deploy, OCS 2007 R2. In
each deployment example, the respective companies implemented
OCS alongside some existing traditional IP telephony deployment.
The case studies build toward a “net” conclusion, with regard to
best network architecture practices for deploying OCS Enterprise
Voice as identified by the deploying company.
Case Study 1: Manufacturing Company
A global manufacturing company with plans to deploy Microsoft OCS
2007 to tens of thousands of employees across the U.S. and worldwide
is currently in the early phases of its rollout. The firm has plants and
offices primarily in North America, but it also has a worldwide reach. It
connects most sites with an MPLS WAN backbone.
3© Copyright 2009. Yankee Group Research, Inc. All rights reserved.
November 2009
Business Driver Behind OCS
The manufacturer was one of the first large adopters of IP
telephony technology at the beginning of the decade, when it made
a mass transition from TDM telephony to Cisco’s then-branded
AVVID IP telephony architecture and later to Cisco CallManager
and Cisco Unified Communications Manager. It was ahead of the
curve with IP telephony in the early 2000s, and the company is
continuing this trend with UC as it enters the next decade.
Unlike the IP telephony migration, the switch to OCS is focused
on improving business processes, as opposed to just moving voice
traffic from one medium (TDM) to another (IP) or one vendor
(Cisco) to another (Microsoft). The manufacturer wants to bring
multiple communications channels under one common interface at
the endpoint (whether mobile or desk-bound) along with a single
back-end server and management infrastructure. The firm also
wants to put underutilized desktop processing resources toward
telephony, with the goal of reducing the company’s total telephony
endpoint/dial-tone footprint. For every employee, the company
currently supports approximately 2.5 “PSTN units” (i.e., desktop
phones, soft phones with assigned numbers, etc., that can reach the
PSTN). This was the result of years of slow migration from TDM
to IP telephony, which ultimately left the company with a complex
mixed environment that led to a sprawling, overprovisioned voice
environment. By consolidating telephony endpoints with OCS,
where voice services are tied to end-user identity and endpoint
PCs, the manufacturer plans to drive that number back down to one
PSTN unit per employee, with a correlated benefit on costs.
Methodology for Rollout
The manufacturing company’s OCS deployment is extensive,
although not complete. Each user in the 100,000-employee
company has Office Communicator on his or her desktop and
connects to a centralized OCS infrastructure for IM and presence.
About 300 employees have been using OCS Enterprise Voice for
about a year, and the company’s goal is to expand to 2,000 end-
users by the end of 2009. By the end of 2010, it expects to be at
12,000. The long-run goal is for the ratio of OCS users to Cisco IP
phone desktop users to be close to 50-50.
The company currently supports its companywide deployment
of OCS for IM, presence and conferencing in its three main data
centers, and it is in the process of adding voice services to these
data centers. OCS servers are in the same locations as its Exchange
infrastructure, which is centralized in two data centers; this is
different from its current Cisco CallManager infrastructure, which
requires dozens of server clusters in locations worldwide in order
to support the total end-user population.
The manufacturer’s OCS Enterprise Voice deployment is
fully interoperable with its pre-existing Cisco CallManager
infrastructure. Currently, Cisco ISR routers are used to connect
all OCS calls to the PSTN via a SIP trunk feature. No upgrade was
required on the Cisco side to support this because the SIP trunking
capabilities are based on a Session Border Controller (SBC) feature
native in the Cisco IOS routing software the company uses. The
interoperability is transparent to users because the dial plans did
not have to be changed.
Issues Experienced and the Approach to Solve Them
Overall, the manufacturing company has experienced no major
network-configuration issues that have affected the performance
or quality of OCS. The company attributes this both to the robust
network infrastructure and the independent underlying nature of
OCS itself, which largely operates independent of its underlying
transport technology and does not rely on network-based controls,
such as RSVP or network segmentation, to ensure quality.
What Worked Well
Because of the manufacturer’s existing Cisco deployment (which
it will retain for the next several years), it already has an extensive
QoS and VLAN structure for segmenting voice traffic and providing
priority queuing and express forwarding on its Cisco LAN and
WAN infrastructures. This will remain because the firm is working
to map its current QoS architecture to the OCS voice traffic.
© Copyright 2009. Yankee Group Research, Inc. All rights reserved.4
Network Considerations for Microsoft OCS Deployments
“In my opinion, if [you] already have [QoS] installed,” says the
manufacturing company’s lead architect for enterprise voice and
UC, “you should be making OCS fit into your QoS architecture.”
To achieve this, the company is mapping the DiffServ priority tags
assigned to OCS voice traffic and mapping this traffic to existing
VLAN and QoS architectures—a relatively simple configuration
exercise. This strategy is the result of two factors: The
manufacturing company still has a very large deployment of Cisco IP
telephony, which requires separate VLANs and express forwarding
settings for LAN-based IP telephony; and VLAN separation and
QoS still offer troubleshooting and delivery guarantees over LAN
links that the company does not want to leave up to chance upon
the first rollout of OCS.
With more employees using PCs and mobile devices as primary
voice interfaces, the number of desktop phones will shrink over
time; as a result, the manufacturing firm will also be able to begin
gradual reduction of Power over Ethernet (PoE) switch ports
deployed in wiring closets throughout its enterprise. Currently,
every Cisco IP telephone connects to a PoE switch port, which
provides both power and network connectivity. Since PoE adds an
approximate 20-30 percent premium to the cost of a switch port,
reducing the need for PoE to desktops could save the company
millions in infrastructure costs in the long run.
“Net” Conclusions
Enterprises will want to leverage their already deployed extensive
IP telephony infrastructures. The QoS and native SIP functionality
within the OCS server stack was a key component to this
company’s migration strategy; the company was able to integrate
OCS users with its incumbent Cisco infrastructure without altering
dial plans or introducing other changes that would make the OCS
environment seem bolted on. This also allowed the manufacturer to
use its existing Cisco SIP-trunking gateway infrastructure instead of
purchasing new equipment.
Case Study 2: Europe-Based Consulting Firm
One Europe-based consulting firm is among the most aggressive
deployers of OCS Enterprise Voice of the four companies profiled.
With more than 6,500 employees across 20 offices, the firm is using
OCS to centralize disparate islands of telephony across its locations
and to provide advanced collaboration features to its employees and
partners via OCS federation.
Business Driver Behind OCS
For years, the consulting firm has envisioned a unified platform for all
channels of enterprise communications, from telephony, conferencing
and real-time chat to voice and e-mail. The company says it bought
into early iterations of IP telephony with an eye toward this ultimate
goal, but the reality of solutions offered over the last five to seven
years was that they were basic PBX replacements that transported
voice using IP networks instead of circuit-switched TDM networks.
In the interim between IP telephony and true UC, the consulting firm
had to fill in gaps, such as multimedia Web conferencing and instant
messaging, with outside services and tools, such as conference hosting
providers or consumer-based IM solutions pushed mainly by the
company’s own employees.
Methodology for Rollout
The consulting firm is on a rapid pace to roll out OCS throughout
its organization and plans to completely transition from its legacy
Nortel PBX platforms to Microsoft OCS Enterprise Voice by
the end of the year. Of the 6,500 employees in the organization,
approximately one third now use OCS for all communications. The
consulting firm’s CIO estimates that it will have all of its end-users
on OCS by the November/December 2009 time frame.
OCS Enterprise Voice still connects externally via Nortel PBXs,
which act as a gateway for OCS SIP traffic and the PSTN. The
firm plans to be off this hybrid architecture within the next three
to six months because it expects its regional telco to make pure
SIP-based trunking services available soon. The SIP trunking service
would tie the OCS Enterprise Voice infrastructure directly into the
carrier’s SIP-based VoIP network, eliminating the need for PSTN/
SIP gateways.
The firm is moving its 20 offices from Nortel telephony to full
Microsoft OCS support at a rate of one office about every two
weeks. Each office had its own IP PBX platform and connected to
the PSTN via a local trunk (although internal calls were routed
over the company’s WAN). As the offices move from Nortel
to Microsoft for voice, the main number and all internal direct
inward dialing (DID) numbers are rerouted through the company’s
headquarters, where its main data center for OCS is hosted. This
allows the firm to reduce receptionist staff at each of its offices and
reassign the workers to other support positions within the firm.
5© Copyright 2009. Yankee Group Research, Inc. All rights reserved.
November 2009
The company is deploying Polycom USB-based handsets, which
connect to end-users’ laptops, to every desktop in the firm. The
Polycom phones are certified with Office Communicator clients
and OCS in general.
Issues Experienced and the Approach to Solve Them
The consulting firm has experienced no real network-related issues
in its OCS deployment so far. Assigning dual 100 Mbps Ethernet
WAN pipes to each location gave the OCS deployment plenty of
bandwidth and low latency, which ensured quick call setups and
good voice quality.
One of the only issues end-users have complained about
during the rollout was the issue of resource contention on
desktop endpoints—particularly among users with older model
PC hardware and OSs. The firm’s CIO says that calls can be
interrupted when end-users copy large files to or from their PCs
over the network while having an OCS voice conversation. Even
though the firm will use USB-based handsets, which can boost
voice quality and offload voice processing from the PC to the
device’s digital signal processor (DSP), voice and data packets will
still contend for bandwidth at the endpoint level. The CIO says
the company plans to move to Windows 7-based workstations in
2010; this will entail upgrading processors and memory on many
older machines that were having the resource contention issue. He
anticipates the upgrade will improve performance for simultaneous
voice and data applications.
What Worked Well
Immediate results of the quick OCS rollout include a more
productive consultancy team, which is driving more customer
interactions—and more billable hours, according to the firm’s
CIO. Desktop sharing and click-to-dial integration for conferencing
and chat are used frequently by consultants giving presentations
to clients on-site. Instead of deferring to other colleagues for
questions beyond their own scope and making notes to follow up,
the consultants can now quickly conference their colleagues into
live presentations via the Office Communicator client. Presence
allows the consultants to see who is available, and connections
are made with a click of the mouse. “This capability lets us show
how we are different from an efficiency standpoint compared to
our competitors, which is crucial in this economic environment,”
says the firm’s CIO. The fact that the company was able to provide
all this without any complex or expensive network upgrades
is a testament to both the firm’s existing high-end network
infrastructure and the unobtrusiveness of the OCS platform.
“Net” Conclusions
While he realizes that not every enterprise can roll out a metro
Ethernet WAN to all of its sites, the consulting firm’s CIO says
that investing in a high-bandwidth network was one of the main
factors of success behind his firm’s OCS Enterprise Voice rollout.
A largely tech-savvy employee base and very large network pipes
allowed the firm to roll out OCS Enterprise Voice at a very rapid
clip—a pace the CIO says actually led to slow days in IT, given how
quickly he is able to turn over offices. “Sometimes we have [IT
staff] not doing anything for a few days at some offices, because the
change went so smoothly. It makes me think we should have been
more aggressive with our timetable.”
Case Study 3: Global Energy Company
The next enterprise operates in over 140 countries and currently
supports more than 15,000 users on Microsoft OCS Enterprise
Voice. The company also has an extensive TDM-based PBX system
from Nortel and other vendors, as well as IP telephony systems
from Nortel. The company is also upgrading its self-managed,
heterogeneous hub-and-spoke WAN architecture to a common
AT&T-hosted MPLS VPN network.
Business Driver Behind OCS
The energy company wanted to consolidate the management of its
voice infrastructure, which was spread across more than 270 PBXs
throughout the world. The company also sought a unified desktop
client experience for all communications channels—e-mail, voice
messaging, chat, telephony and video. The company is also keen
on extensive use of federation with OCS to allow for greater
connectivity with key external partners.
© Copyright 2009. Yankee Group Research, Inc. All rights reserved.6
Network Considerations for Microsoft OCS Deployments
Methodology for Rollout
In initially deploying OCS 2007 over the WAN, the energy
company’s network team calculated the average number of users
and the average number of projected phone calls employees make
on a daily basis. It then calculated the bandwidth that would be
consumed on average per site. Based on that, the firm determined
the sites where it could enable Enterprise Voice and video services
in the short term, prior to network upgrade. The company also
factored in other bandwidth consumption and usage factors, such
as its global, centrally hosted deployment of SAP, which is accessed
by over 200 sites worldwide. During that phase, the company
hosted OCS 2007 from its data centers in Amsterdam, Houston
and Singapore to serve its worldwide client base.
No significant changes to the LAN were necessary to initially
accommodate OCS because the deployment was tailored to the
in-place network. Although sites have existing VLAN and QoS
architectures in switches to support Nortel-based IP telephony,
these will be abandoned when OCS becomes the predominant
voice application. On the WAN side, QoS will be used to prioritize
OCS voice traffic on the AT&T MPLS WAN.
Beyond this initial deployment, AT&T (acting as the energy
company’s outsourcer for network and telephony) is upgrading
the deployment from OCS 2007 to OCS 2007 R2 and rolling
out a global MPLS network to virtually every site. The goal is to
eventually enable OCS for Enterprise Voice and video at every site.
AT&T will deploy dual MPLS links to each site for link redundancy.
For smaller sites that do not warrant dual MPLS links, the company
will deploy local resiliency capabilities such as voice gateways,
which will allow the sites to make outbound PSTN calls in the
event of a primary MPLS link failure. Since AT&T will be managing
the OCS deployment on behalf of the company, the OCS server
infrastructure will be deployed at AT&T data centers in Europe, the
U.S. and Southeast Asia.
Issues Experienced and the Approach to Solve Them
The IT architect at the energy company jokingly says the greatest
challenges are keeping up with end-user demands to deploy OCS
more widely to more sites and to enable new features such as
mobile device support.
As with the consulting firm, the only recurring issue the energy
company faces is with voice quality on older PC endpoints (i.e.,
Windows 2000 Professional, which is still widely used throughout
the organization). If employees use CPU-intensive applications on
these desktops or copy large files to or from their PCs while on an
audio conferencing call, this leads to interference in voice quality,
which can make calls sound choppy. Also similar to the consulting
firm, the energy company anticipates these issues will lessen as
it upgrades its end-users to Windows 7 in the near future. Also,
general user awareness about running multiple applications or
downloading/uploading large amounts of data will also increase as
the deployment matures.
What Worked Well
Overall, according to the energy company’s IT architect, voice
quality is an improvement over any previous IP telephony or
TDM voice solution due to the wideband (16 kHz) audio used
on peer-to-peer voice connections over the LAN. While some
initial users complained about voice quality at some sites where
underprovisioned WAN links were used, the advanced media
capabilities built into OCS endpoints have done well in adjusting for
resource contention on the WAN.
“Net” Conclusions
Upgrades to the WAN (to MPLS), as well as usage analysis and
right-sizing of branch office links, were among the most critical
aspects of the energy company’s project and have led to the success
of this rollout so far. At this point, process and implementation
timing challenges were the only drawbacks in the company’s rollout;
as for the technology, it has worked as advertised and has required
minimal network reconfiguration or workarounds. Looking back,
says the IT architect, the company probably would not have rolled
out its OCS deployment in parallel with moving to AT&T for hosting
and an MPLS network overhaul. Performing major simultaneous
changes to the network introduced complexity and delays that
could have been avoided had the project been taken on piecemeal.
7© Copyright 2009. Yankee Group Research, Inc. All rights reserved.
November 2009
Case Study 4: European Telecommunications Company
A regional telecommunications company operating in Europe has
plans to deploy OCS Enterprise Voice across 120 office locations.
The company uses almost all Cisco IP telephony today, as well as
circuit-switched and packet-based telephony systems from Siemens,
Nortel and Alcatel in a few offices. Most non-Cisco sites have TDM-
based equipment.
Business Driver Behind OCS
The company wanted to leverage its ubiquitous Windows desktop
environment to include voice, messaging and presence applications
under one umbrella. What really pushed the idea of OCS as the
main voice platform was the 2008 acquisition of a smaller Web
conferencing service provider. The acquired company had used OCS
more aggressively, with a full deployment of OCS Enterprise Voice
to its 300 users. The company had started with Microsoft LCS and
stuck with the technology as it evolved into OCS. While it is not
yet deployed to all employees’ desktops, Office Communicator is
used by a majority of workers on their mobile devices, including
Windows Mobile and RIM BlackBerry.
Methodology for Rollout
The carrier’s own deployment of OCS IM and presence started in
late 2007 with 50 users and quickly expanded to 600 users by mid-
2008. It now has 17,000 employees accessing the system for IM and
presence. The carrier also uses federation with its partners via OCS.
Two redundant data centers host the OCS server infrastructure
inside the carrier. Multi-gigabit WAN connections link all three
of these data centers. External PSTN connections are all routed
through a Nortel Communication Server (CS) 2100—an IP PBX
still used to support a large portion of employees with Nortel IP
phones. The CS 2100 resides in one of the two data centers.
The carrier did little network engineering to augment the
performance of OCS voice. It relies on the OCS codecs and
endpoint software to provide voice quality, as opposed to
implementing separate VLANs or QoS prioritization on the WAN
or LAN. While the company did have a QoS/VLAN infrastructure
in place for its existing IP telephony deployment, OCS will not
be mapped to this scheme. This is because the company plans
to quickly move off its existing IP telephony platform to OCS
Enterprise Voice, unlike the manufacturing company profiled in Case
Study 1, which must support parallel Cisco/Microsoft OCS voice
infrastructures into the foreseeable future. (The manufacturing
company’s engineering team says the configuration effort will be
worth the benefit of being able to segment OCS traffic in VLANs or
apply Layer 2 QoS controls to the traffic.)
Issues Experienced and the Approach to Solve Them
The major network reconfiguration the carrier faced was related to
its extensive internal network of Check Point firewalls—a complex
infrastructure with multiple zones and VPN segments. This had to
be re-engineered when OCS was deployed. Firewalls prevented
the any-to-any connection environment necessary for OCS, which
meant some employees could initiate chat or voice sessions, but
others could not call or message back due to zone restrictions. This
was alleviated by configuring the Check Point firewalls with rules
that permitted bi-directional signaling and codec traversal for OCS
traffic. Also, the Microsoft OCS Mediation Server—a critical piece
of infrastructure to the deployment—was hosted in a data center
that could not be accessed by all users. The Mediation Server was
moved to another data center that permitted wider access.
What Worked Well
The software stack and corrective codecs for voice allowed
the carrier to deploy OCS Enterprise Voice without any major
configuration changes to its LAN or WAN environments. The
customer decided that voice quality could be adequately assured
via endpoint software and close monitoring of voice streams via the
Quality of Experience (QoE) Monitoring Server—a platform for
ongoing voice traffic and call quality monitoring and reporting that is
part of the OCS Enterprise Voice suite. This allowed the company to
provision voice as just another application or feature of its merged
OCS infrastructure, rather than having to treat the voice rollout as a
separate, laborious process of network testing and fine-tuning.
“Net” Conclusions
Since bandwidth was not a great concern—considering that the
carrier could provide as much as it needed from its own network—
the carrier was able to rapidly migrate and build out its OCS
environment, moving relatively quickly from small OCS deployment
to integration with the larger organization, which had previously
used LCS. The end-user interface made migration simple from
an end-user-adoption standpoint: Workers just kept using Office
Communicator on endpoints.
© Copyright 2009. Yankee Group Research, Inc. All rights reserved.8
Network Considerations for Microsoft OCS Deployments
OCS and Your Network: III. Recommendations and Best Practices
The previous case studies highlight the drivers behind each
company’s OCS deployment, the issues and challenges they
faced and examples of how network configurations and existing
environments can affect an OCS rollout. Next, we examine some
specific issues around network planning and deployment using
best practices drawn from the experiences of the four profiled
companies and the OCS user community at large.
Complete a Pre-Deployment Network Assessment
Each enterprise profiled assessed the capabilities of its network prior
to rolling out OCS Enterprise Voice. A critical first step in assessing
the network is to determine bandwidth availability and average
call usage per site. Provisioning voice and determining bandwidth
needs for a small-scale pilot deployment—perhaps to a group of
IT professionals testing the system, or to a select group of power
users—can be done by looking at call detail records from an existing
PBX or IP telephony system to gauge usage patterns. If an entire
branch office or department is being moved into production with
OCS, however, pre-determining how the network will handle this
new type of traffic and call volume on a more detailed level is critical.
In the case of the global energy company, call capacity and
bandwidth planning were part of the deployment process. The
energy company calculated the number of users at its various
remote sites and factored in the average monthly volume of calls
made from these locations. The company’s IT group also assessed
overall interest in video among the locations and factored this
into the estimates. The company then looked at the total available
bandwidth for each site to determine if it would be ready as-is for
an OCS Enterprise Voice deployment, or if more lines or larger
pipes needed to be provisioned.
Analyze Topology Schemes
Each enterprise interviewed for this report uses a centralized
deployment model for its OCS Enterprise Voice setup. This is one
of the main drivers for OCS in general—centralization of voice
call processing instead of dispersed islands of PBXs at remote
sites, or up to a dozen quasi-centralized IP PBXs, as in the case
of the manufacturing company with its multiple Cisco Unified
Communications Manager clusters.
Each user we spoke with used a centralized deployment model for
hosting OCS servers for the entire enterprise; in most cases, OCS
was deployed alongside the company’s existing Microsoft Exchange
messaging infrastructure. If enterprises had already deployed OCS for
presence, IM and conferencing, they deployed OCS Enterprise Voice
services within this infrastructure instead of deploying additional
servers in more locations in order to support enterprise telephony.
In the case of the manufacturing company, the firm is hosting OCS
from three data center sites in North America. This gives the
company localized geographical coverage for sites near each data
center and provides redundant OCS resources in case of a server
or site outage. This is the current approach used by all customers
interviewed in this paper: to have an entire off-line failover site
waiting to assume the burden of all voice traffic in the event of a
primary site failure. Although real-time failover features, where OCS
sessions would be seamlessly handed off from a failing site to a live
site, are not yet supported, the manufacturing company says it has
enough faith in Microsoft’s OCS road map to deploy only three sites
in anticipation of this feature in future revisions of the platform.
In addition to centralizing data center resources for enterprise
telephony, enterprises can use an OCS deployment as an
opportunity to right-size and optimize their WAN deployments
for branch offices. As was the case with the energy company and
European carrier, local gateways can still be used to provide backup
dial tone.
At the time of our interviews, the enterprises’ deployments of
OCS Edge Services were in various stages. The manufacturer
used Edge Services to federate its OCS resources with key
partners and customers; separate remote access or authentication
infrastructures were not needed in order to share presence,
conferencing and IM with outside partners.
Full Edge Services deployments are on the road map for each of
these companies. This will allow the organizations to further migrate
away from legacy IP telephony and remote access infrastructure,
such as IPSec VPN tunneling, to access OCS resources, which is a
method still widely used (e.g., the manufacturing company). Edge
Services will allow mobile and external users to access OCS without
VPN tunneling; also, internal users will be able to access external
OCS users directly from the OCS Edge Services infrastructure at
the network demarcation point.
9© Copyright 2009. Yankee Group Research, Inc. All rights reserved.
November 2009
If You Have QoS, Use It
Each enterprise used QoS mechanisms, mainly DiffServ, to prioritize
voice media packets traversing WAN links. However, they used
little traffic shaping or prioritization on LAN connections for
Microsoft OCS Enterprise Voice. If practical to the customer,
Microsoft generally prescribes wiping VLAN segmenting and 802.1p
prioritization from a LAN architecture overall, with the idea that
right-sizing the network for bandwidth and latency has greater impact
on quality for less cost. Further, Microsoft’s RTAudio codecs and
features such as Forward Error Correction (FEC) can compensate
for less-than-optimal network conditions or constraints.
Of course, QoS and other flow management techniques can still
be considered. Enterprises can keep in place their predefined QoS
schemes from previously deployed IP telephony products, such as
Cisco Unified Communications Manager or Nortel Communications
Server 1000. This was the case with the global manufacturer, which
had a complete network-based QoS architecture already built on
both the LAN and WAN to segment and prioritize IP voice signaling
and payload traffic. The company plans to map OCS Enterprise
Voice traffic into the same 802.1p traffic prioritization and 802.1Q
VLAN tagging scheme it currently has.
In the case of the energy company, a QoS architecture is already
in place for the worldwide deployment of SAP, which the company
hosts from central data center locations in Europe, North America
and Asia. As it transitions these data centers to AT&T and moves
to the carrier’s global MPLS IP VPN, it will continue with its current
prioritization of SAP over the WAN (using DiffServ controls
mapped to MPLS switch labels) and will incorporate OCS voice
traffic into this scheme as well. The energy company considers SAP
and OCS to be the two highest-priority traffic types for operating
its business and will prioritize both flows over all others.
Become Familiar With Ongoing Management and Monitoring Tools
Another common denominator among the enterprises interviewed
is extensive use of the QoE server as the centerpiece of their
ongoing voice quality management and monitoring strategy. In past
IP telephony deployments, users typically had to rely on third-party
tools for supporting management and quality assurance of real-time
communications traffic on an enterprise network. These tools were
based in one of two camps: network-related products for measuring
packet loss and jitter of IP traffic streams, and voice quality analysis
tools (from vendors such as Qovai, NetQoS and Clarus Systems)
that delivered automatically generated mean opinion score (MOS)
analysis of voice call quality by sampling traffic streams.
The issue with such approaches was that they separated two
types of metrics: one on the performance of packet delivery of
an IP network; the other on the sound quality of packetized voice
delivered over an IP network. It was up to network engineers to put
these two areas of management together in order to troubleshoot
and fine-tune enterprise IP telephony deployments. The fact that
vendors of IP telephony gear did not supply such tools with their
systems also muddled the issue and forced end-users to do extra
work to find measurement and management tools that were
certified with their respective IP telephony platforms—or pay high-
priced, specialized consultants to do this.
Microsoft’s QoE server takes into account multiple factors that can
affect voice quality and system performance as perceived by end-users.
To start with, it goes beyond simple, passive network taps or probes;
the server has the ability to gather statistics on the overall quality of
an individual’s connection or group’s connections, taking into account
both the performance of voice traffic on the wire and the experience
of the end-user at the endpoint. Active monitoring, trend analysis and
end-user complaint mediation features are also included.
Some of these enterprises looking for a cross-platform view used
a secondary tool for the measurement and monitoring of voice
quality and overall network performance in conjunction with the
Microsoft QoE server. It’s no surprise that the carrier Yankee
Group interviewed, for whom running and optimizing networks is a
core business, is the biggest proponent of this approach.
The European regional carrier uses traffic measurement tools from
Ipanema Technologies to analyze multiple types of RTP traffic and a
variety of codecs traversing the carrier’s network. Along with this
method, the carrier uses Microsoft QoE server to specifically measure
OCS traffic as well. This combined approach gives the provider a large-
picture view of how OCS fits into the network as a whole, with the
QoE server used for OCS-specific management and monitoring.
Overall, use of a secondary tool is recommended for enterprises,
as opposed to solely relying on the QoE server for voice
troubleshooting and monitoring. Tools to consider are those
that can analyze OCS Enterprise Voice traffic; certified partners
providing such tools include NetQoS and Psytechnics. Such tools
can provide a good secondary analysis outside the QoE metrics
used by the Microsoft platform.
© Copyright 2009. Yankee Group Research, Inc. All rights reserved.10
Network Considerations for Microsoft OCS Deployments
Consider Network Services Provisioning and Carrier-Provided SLAs
Many enterprises that are centralizing voice delivery for the first
time with OCS are also crafting service level agreements (SLAs)
with carriers around IP voice. In the case of the global energy
company, for example, this is the first time global voice delivery
could be included in an SLA with a carrier, since the company’s voice
infrastructure in the past was made up of over 270 PBXs connected
to the PSTN by various providers.
The energy company, which has run a centralized, global
deployment of SAP for several years, has had various SLAs with
its data carriers for delivering that traffic to branch offices. Now
that both voice and applications traffic will be delivered over a
single pipe (the AT&T MPLS network) and from a single source
(AT&T’s regional hosted data centers), the company is working
with the carrier to craft SLAs that will take into account whether
OCS voice traffic is delivered at a rate below the acceptable level
of the SLA. This is where the QoE server comes into play directly
as a potential revenue-saving opportunity. The QoE server can be
used to flag voice traffic that falls below a certain quality threshold
from both a network and endpoint perspective. The company is
working with AT&T to extract some of the network-related metrics
and parameters measured by the QoE server to use those as a
foundation for the SLAs.
Prepare Security Validation and Firewall Topology, Configuration Adjustments
Some enterprises faced security challenges related to firewall
topology and architecture during their OCS deployments. Firewalls
and IP telephony have a history of not playing well together. In early
VoIP deployments, network engineers had difficulty getting firewalls
and technology schemes such as network address translation
(NAT) to work well together. To this point, many enterprises have
avoided this issue by using VPN tunneling to connect VoIP clients
or resources on opposite sides of a firewall. The issue is also being
addressed by the development of standards that will allow for more
seamless inter-network VoIP connectivity; among these efforts is
the Interactive Connectivity Establishment (ICE) protocol, used in
OCS, for firewall and NAT traversal of SIP-based VoIP traffic.
Security and network considerations are not only focused on
enterprise boundaries, but on internal network segments as well.
As shown in the case of the regional European carrier, a firm that
operates an extensive internal firewall infrastructure can run into
trouble when deploying OCS if it does not account for how voice
traffic will traverse various security zones across an organization.
It is essential to place critical OCS infrastructure components on
segments of the network that are accessible to all employees.
In general, firewalls, traffic inspection gateways and other in-line or
out-of-band security appliances that will be traversed by OCS traffic
should only enforce policy at the routing layer. Firewalls should be
configured to recognize and allow pass-through of traffic across key
external and internal user ports, such as Ports 5061, 5062 and 443
for OCS Access and Audio/Video Edge Servers and Ports 443 and
8057 for Web Conferencing Edge Servers.
OCS’s end-to-end security model includes secure real-time
protocol (SRTP), which secures the audio stream of OCS Enterprise
Voice communications using a 128-bit AES encryption standard
to prevent against conversation interception or other tampering
with the RTP stream. Also, transport layer security (TLS) protocol
is used to secure SIP-based signaling, which prevents protocol-
based spoofing attacks at the signaling protocol layer. With these
safeguards in place at the OCS Enterprise VoIP application layer,
enterprises deploying OCS Enterprise Voice should adopt a more
open, any-to-any topology model for connectivity—at least in
terms of the pieces of their OCS infrastructures. Enterprises with
past experience in IP telephony and security best practices will also
have to rethink previous methods of cloistering segments of the
network exclusively for voice, or extensive use of access control
lists for blocking access to IP PBXs, or limiting what types of traffic
endpoints can receive and send.
Another general rule of thumb followed by all enterprises
interviewed for this report is the inclusion of their respective
security teams in the planning and testing of OCS infrastructure.
Federation and the prospect of opening up internal directories
to external partners was a serious undertaking from a security
standpoint in each case study. The enterprises all required sign-off
from their respective IT security teams to complete this, as well
as an audit of what types of communications and resource sharing
would be allowed among federated partners.
11© Copyright 2009. Yankee Group Research, Inc. All rights reserved.
November 2009
OCS Costs and Benefits: A Breakdown IV. of Potential Savings
Enterprises are moving to Microsoft OCS Enterprise Voice to
improve end-user productivity, add powerful collaboration tools
such as video and presence, and make business-to-business
communications more open. This does not mean these enterprises
aren’t interested in finding ways to cut existing infrastructure costs
with OCS as well. This section analyzes some areas for cost savings,
based on some of the experiences of the four organizations profiled.
Network Right-Sizing
Organizations such as the global energy company are realizing
increased savings and management cost efficiencies by re-evaluating
the bandwidth requirements for all branch office voice connections
and redeploying WAN links accordingly. Previously, the energy
company managed a complex tangle of varying point-to-point
MPLS and VPN circuits across its multiple locations. Obviously
this infrastructure was deployed prior to the OCS rollout, so the
bandwidth provided did not take into account the actual calling
patterns and voice bandwidth utilization of these sites; as a result,
many sites were overprovisioned in terms of WAN bandwidth
requirements for voice, while links at other sites were unnecessarily
squeezed. Above most other cost-saving factors, the exercise of
evaluating how much network bandwidth will be required for OCS
Enterprise Voice and readjusting the infrastructure accordingly is
among the most powerful cost-saving aspects of an OCS rollout.
Back-End Equipment
Server consolidation and equipment reduction will be a very large
cost-reducing factor among many of the enterprises interviewed.
In the energy company’s case, it will decommission more than 200
PBXs and other IP telephony gear at its remote sites throughout the
duration of the rollout, as sites come online with OCS voice. Taking
into consideration the cost of ongoing maintenance, lease of some
equipment and other factors, this move will, over time, equate to a
savings in the tens of millions of dollars annually.
The consolidation of call control, as well as external telephony
connections, will also help reduce the number of PSTN gateway
interfaces the company currently uses. Prior to OCS, even Nortel-
based VoIP sites that included multiple offices connecting to an IP
PBX still required an external PSTN gateway link for outbound and
incoming calls. Putting the OCS servers into the AT&T data center,
where OCS can connect directly to AT&T’s SIP trunking service,
will also consolidate this entire infrastructure of hundreds of
gateways down to essentially three in AT&T’s data centers in Asia,
North America and Europe.
Endpoints
Another powerful cost-saving force in the realm of equipment
reduction is the use of PCs as IP telephony endpoints, which allows
for reduction of IP phones on desktops. This was cited as a driver
for the four organizations we talked to for this report. In the case of
the manufacturing company, the goal is to get the number of phones
per employee down from a range of about 2.5-to-1 to around 1-to-
1—that is, each employee’s desktop PC would become his or her
telephony endpoint as well. The manufacturing company estimated
that its total IP phone reduction could be in the tens of thousands
of handsets.
While most of the cost of the phones has already been depreciated,
the move to a phoneless desktop will save the manufacturing
company millions of dollars on desktop phone replacement costs
in the long run. Considering the list price of a new Cisco IP phone
starts at $250 for a basic-feature handset, the manufacturing
company would be saving as much as $10 million for an enterprise-
wide upgrade, which would include between 80,000 and 100,000
employees. There is also a potential for cost savings on the
network side, as fewer phones will require fewer PoE ports, which
could result in lower future LAN switch acquisition costs. Energy
consumption will also be reduced, since the company will no longer
be required to inject power as broadly over its structured cabling
plant. Additionally, the company would be able to provision remote
workers, teleworkers and even external contractors or partners
with OCS Enterprise Voice-based telephony without having to
deploy expensive VPN, remote access and hardware telephony
endpoints to these constituents.
© Copyright 2009. Yankee Group Research, Inc. All rights reserved.12
Network Considerations for Microsoft OCS Deployments
Advanced Application Services
Conferencing is one of the most dominant cost-saving drivers
named by the enterprises as part of the OCS feature set. In the
case of the Europe-based consulting firm, the company’s 6,000
employees had frequently used external conferencing services
for both internal and external meetings. The use of various
conferencing provider services left employees working on platforms
with inconsistent interfaces, while requiring users to track call-in
numbers and manage various downloadable plug-ins to support an
array of meeting platforms shared with external partners and with
members of their own organization. In addition, employees were
being charged for these various services, which made funding and
accounting of costs difficult across the various business units using
the services.
Centralized conferencing covers all channels used by the company:
Web, voice and video with integrated chat and desktop sharing. The
central platform also provides a common interface familiarity across
the organization, as well as easier conferencing setup tools; any type
of conference can be easily initiated from a voice, chat, e-mail or
video communications session.
Also, federation allows the company to easily set up conferences—
including Web, video and voice—with other federated partners,
customers and external parties. This allows the company to
continue to keep its travel costs down while lowering its costs
further by using the internally hosted OCS platform instead of an
outside provider. Additionally, the wideband audio of the OCS
conferencing platform provides a superior quality to previous
solutions, making such meetings more resonant and productive.
Among enterprises in general, Web and video conferencing is also
seen as the greatest cost-saving component among all the areas of
UC. According to Yankee Group's Anywhere Enterprise: Large—
2009 Transforming Infrastructure and Transforming Applications
Survey, Wave 1-4, this is regarded as the No. 1 cost-reducing factor
of a UC deployment among enterprises that have deployed or are
considering UC.
ConclusionsV.
Each featured enterprise’s deployment of OCS Enterprise Voice
uses a different approach from past efforts around network voice/
data convergence or IP telephony. Users of the platform see OCS as
a strategic step forward and as a business-enabling communications
tool, as opposed to a tactical implementation of a technology to
save money or consolidate resources. The underlying theme among
all the enterprises is the decoupling of enterprise voice services
from the network infrastructure; the long-promised goal of “voice
as just another application” is starting to become realized in many of
these organizations. If done correctly, great organizational TCO and
end-user productivity gains are possible.
To that end, however, enterprises are still faced with getting
OCS Enterprise Voice to work on their networks. While
OCS Enterprise Voice offers many advanced features that can
compensate for network congestion and low bandwidth, such as
software and codecs that provide error correction and audio quality
improvement, careful consideration must still be given to how OCS
Enterprise Voice is deployed throughout an enterprise. Deployment
plans must still tackle several issues in order for implementation
to succeed, including network topology, integration with legacy
telephony systems, endpoint device scenarios and bandwidth
considerations—especially for branch and remote offices. Based on
the experiences of the OCS Enterprise Voice deployers detailed in
this report, the following conclusions can be drawn:
Network considerations should be included in a deployment plan
OCS Enterprise Voice introduces new bandwidth management,
voice quality assurance and other technologies that allow the
service to boldly go where enterprises have feared to send IP
telephony in the past—in particular, on high-latency and/or
bandwidth-constrained connections for remote or mobile users.
This capability opens up new possibilities in terms of use cases
and deployment scenarios, such as right-sizing WAN connections
and reducing VoIP-specific network constructs, such as VLAN/
QoS architectures and PoE switch infrastructures. Nevertheless,
simply throwing OCS Enterprise Voice onto an existing network
is not recommended unless bandwidth and latency are already
well provisioned in the network. Careful consideration must be
given to network topology (such as internal and external firewall
and security zone boundaries), deployment of services relative to
geographical location of remote users and branch offices, and where
QoS and traffic prioritization schemes might be applicable, such as
over low-bandwidth or long-distance WAN connections. The good
news is that the major Herculean tasks facing IP telephony projects
of the past—complete LAN/WAN redesigns and upgrades, or
introduction of new QoS protocol schemes such as RSVP—are no
longer part of the equation.
13© Copyright 2009. Yankee Group Research, Inc. All rights reserved.
November 2009
Consolidation is key:• All of the enterprises interviewed for
this report used their OCS Enterprise Voice deployments as
an opportunity to consolidate voice communications into a
centralized service delivered from a small number of locations.
Distributed call control servers, gateways or other VoIP-enabling
CPE can be minimized, reducing equipment costs, management
complexity and overall TCO. To that end, those who have
deployed the technology should regard OCS Enterprise Voice
as a service similar to e-mail, corporate IM or other centralized
applications and services. Replicating this central infrastructure
over a small handful of data centers—anywhere from two to
four—is also the consensus approach taken by the enterprise
deployments highlighted in this report. By doing this, deployers
ensure that all OCS services will remain available in the event
of a network or data center failure. At the same time, they are
also anticipating future advancements that will allow for live-site
redirection and global live failover scenarios in future iterations
of OCS Enterprise Voice.
Measure, monitor, adjust, repeat:• Each enterprise in
this report found real value with the QoE server as a tool for
measuring all aspects of end-user voice quality experience—from
network performance in terms of packet delay, latency and
congestion, to perceived audio quality on endpoints. Unlike tools
used to measure performance and quality of IP telephony in pre-
deployment or ongoing integration scenarios, the QoE server is
designed to be an ongoing tool used frequently in tight conjunction
with OCS Enterprise Voice for maintenance and monitoring.
Enterprises going into an OCS deployment should regard this
platform as a future everyday OpenView- or Unicenter-like
systems management tool, not as a specialized piece of network
troubleshooting equipment brought out only during deployment
tests or to fix specific problems on the network.
Build upon existing engineering:• Like any major technology
displacement, the introduction of OCS Enterprise Voice will
require some parallel coexistence of previous enterprise voice
systems. At the very least, enterprises will initially have to
tie OCS Enterprise Voice servers to existing IP PBX or VoIP
gateway infrastructure in order to allow OCS clients to make
external calls over the PSTN. This is where the flexibility of OCS
can be used to adapt to existing polices without cumbersome
changes. Existing QoS schemes, set up for legacy IP telephony
systems, can remain in place to support workers as they
transition from old platforms to OCS Enterprise Voice. For
organizations looking at long-term mixed environments of IP
telephony and OCS Enterprise Voice, OCS traffic can be mapped
to existing traffic-shaping and network segmentation schemes
for VoIP, provided that such setups do not interfere with OCS
features and functions.
Endpoint endgame:• Enterprises should also consider
how—or if—they will transition employees who use IP
desktop handsets to PC-based Office Communicator clients
with headsets. Doing so can lead to a quick cost reduction and
simplification of network architecture: The former is achieved
by decommissioning expensive IP handsets on desks; the latter
is realized by decreasing the need for LAN switch-based PoE
to power phones at every desktop. Another consideration
is end-user acceptance. Workers used to lifting a receiver to
make a phone call may find the transition hard to make; options
to help with this include USB-attached handset devices that
are compatible with Office Communicator software. If some
employees are heavy mobile phone users, such workers could
be encouraged to use their mobile devices as primary voice
endpoints while at their desks or out of the office.
OCS Enterprise Voice Deployment FAQsVI.
The following is a list of common issues or concerns, presented in
question form, that the four case-study organizations faced around
their respective deployments of OCS Enterprise Voice, specifically
regarding network issues.
© Copyright 2009. Yankee Group Research, Inc. All rights reserved.14
Network Considerations for Microsoft OCS Deployments
What common network-related trouble spots might I expect to see upon deployment?
Among the four enterprises examined in this paper, one major
network-related trouble spot highlighted was the deployment
of OCS Enterprise Voice across an infrastructure that is heavily
segmented via firewalls and other access control gateways. For
security and compliance purposes, many organizations use these
tactics to create secure zones for segmenting various departments,
or for keeping public and private LANs and extranet zones
segmented from each other. When deploying OCS Enterprise Voice,
however, enterprises must consider how OCS traffic will traverse
security zones. Also important to consider is the deployment
of OCS servers throughout the enterprise, taking into account
whether or not all users will be able to access the servers, given
their security zone. The “any-to-any” collaborative nature of OCS
can run into a brick (or fire) wall very quickly if these issues are not
worked out before wide-scale rollout.
How does OCS support QoS?
OCS supports the DiffServ model for QoS, and this is the
recommended approach if enterprises determine that a low-
bandwidth or a highly congested WAN connection used to provide
OCS Enterprise Voice services could be improved with traffic
engineering. In general, enterprises deploying OCS Enterprise Voice
view QoS as a best practice for WAN connections; on LAN links,
QoS is less critical. While some enterprises deployed previous 802.1p
packet prioritizing schemes on their LANs for legacy IP telephony
systems, generally, enterprises are finding that such controls are not
necessary for peer-to-peer LAN connections with OCS.
What are the available disaster recovery networking plans for OCS today, and what is on the road map?
Currently, OCS provides client redirection failover capabilities,
allowing clients to connect and re-register with secondary OCS
servers in the event that primary servers become unavailable due to
hardware, software or network failures. This type of failover does
not allow for seamless continuation of communications. Calls and
conferences with external parties are dropped in such a scenario.
However, the OCS road map includes capabilities that would allow
for seamless, live-call failover of voice traffic, as well as active/active
backup scenarios, where multiple instances of OCS Enterprise
Voice can serve various groups of end-users, with each set covering
for the other if one group of servers becomes unavailable. Most
enterprises deploying OCS Enterprise Voice today are building their
network and data centers toward this future model in anticipation
of the OCS road map.
What are the bandwidth requirements of OCS codecs?
A peer-to-peer enterprise OCS voice call, using the Wideband
RTAudio (16 kHz) codec, consumes 35 Kbps of bandwidth per
user. When video is added to an internal peer-to-peer call, another
260 Kbps of bandwidth is consumed. A server-hosted RTAudio
narrowband (8 kHz) connection, which connects end-users to the
PSTN, consumes 30 Kbps of bandwidth. For conferencing, OCS
uses the Polycom Siren protocol, which consumes 22 Kbps of
bandwidth per participant endpoint, and an additional 260 Kbps
of bandwidth when video is added. PSOM, the Web conferencing
and collaboration protocol used in OCS, consumes 10 Kbps.
For an example of a real-use scenario, putting together multiple
protocols, a remote conferencing session with video, conferencing
and collaboration would consume approximately 292 Kbps of
bandwidth. Here is an area where enterprises must take care in
capacity planning and bandwidth allocation for their deployments,
since sites that use older, lower bandwidth links, such as fractional
T-1 or ISDN, could become saturated quickly if multiple audio and
video conferencing features are spun up quickly.
How is the QoE Monitoring Server used in my network?
Microsoft’s QoE Monitoring Server is a centralized repository for
statistics about the performance of OCS voice and video traffic on
the network. OCS servers and endpoint clients generate data on
the performance of their call sessions, and this data is collected
by a centralized QoE Monitoring Server. The server takes into
account multiple factors that can affect voice quality and system
performance as perceived by end-users. This includes multiple types
of mean opinion score (MOS) metrics, such as voice quality being
sent and received by endpoints, and network-wide voice quality
reflected in MOS data. Basic network performance metrics, such
as delay, jitter, packet loss and traffic degradation, are also factored
into QoE Monitoring Server reporting.
© Copyright 2009. Yankee Group Research, Inc. Yankee Group published this content for the sole use of Yankee Group subscribers. It may not be duplicated, reproduced or
retransmitted in whole or in part without the express permission of Yankee Group, One Liberty Square, 7th Floor, Boston, MA 02109. All rights reserved.
All opinions and estimates herein constitute our judgment as of this date and are subject to change without notice.
Yankee Group Link
Yankee Group Link membership brings clients the insight, analysis and tools to navigate the global connectivity revolution. It provides timely, actionable and
accessible research and data that analyze the impact of connectivity and the transformation it will create in driving enterprises and consumers to an Anywhere
society. The result is an experience that no other market research firm can provide.
Link ResearchYankee Group’s qualitative research forms the core of our offerings, with analysis focused exclusively on the transformational effects of the connectivity revolution.
Our research reports arm you with the insight and analysis to make the right decisions today and tomorrow.
Link Data
Yankee Group’s quantitative data analysis includes monitors, surveys and forecasts. Together with Link Research, our data connects you to the information you
need to make the most informed strategic and tactical business decisions.
Link InteractionConnect one-on-one with Yankee Group analysts to get answers to your most strategic and critical questions, as well as gain deeper insight into research and
trends. We encourage you to have direction interaction with analysts through ongoing conversations, conference calls and briefings.
Link Consulting
Who better than Yankee Group to help you define key global connectivity strategies, scope major technology initiatives and determine your organization’s readiness to
undertake them, differentiate yourself competitively or guide initiatives around connectivity change? Our analysts apply Yankee Group research, methodologies,
critical thinking and data to produce expert, timely, actionable results.
Link Events
The Anywhere revolution won’t wait. Join our live debates to discuss the impact that ubiquitous connectivity will have on your future. Yankee Group’s events—
live and online—offer our clients new insight, knowledge and expertise to better understand and overcome the obstacles to succeed in this Anywhere revolution.
Yankee Group—the global connectivity expertsThe people of Yankee Group are the global connectivity experts—the leading source of insight and counsel trusted by builders, operators and users of connectivity solutions for nearly 40 years. We are uniquely focused on the evolution of Anywhere, and chart the pace of technology change and its effect on networks, consumers and enterprises. For more information, visit http://www.yankeegroup.com/.
European Headquarters56 Russell Square LONDON WC1B 4HP UNITED KINGDOM 44-20-7307-1050 phone 44-20-7323-3747 fax
Yankee Group has a global presence including operations in North America, Europe, the Middle East, Africa, Latin America and Asia–Pacific. Contact us at:
Corporate HeadquartersOne Liberty Square 7th Floor BOSTON, MASSACHUSETTS 02109 617-598-7200 phone 617-598-7400 fax