Results tagged “microsoft” from IP Communications and Technology

CNN is reporting that Microsoft has abandoned its attempt to acquire Yahoo.

"After careful consideration, we believe the economics demanded by Yahoo (YHOO, Fortune 500) do not make sense for us," said Microsoft (MSFT, Fortune 500) CEO Steve Ballmer.

Have to hand it to John C Dvorak who has insisted from the beginning, despite the popular view, that this deal made no sense and that it would never happen.

Stumble It!

As part of a continuing series on Office Communications Server 2007, this article will discuss the product's native telephony capabilities.

As I've asserted many times, Unified Communications (UC) is an architecture that may include many functional components, enablers and features. Presence, Unified Messaging, Click-to-Dial, Simultaneous Ring, and mobility are just some of the attributes that are often associated with UC. All of those play an important role in UC but the core functional component of UC remains telephony. In the context of this article, telephony refers to all of the features and functionality associated with an enterprise-class business voice service. Modern telephony services are now IP-based, either in the form of a premise-based IP-PBX, a hosted IP Telephony service or various hybrid models.

When Microsoft announced the release of OCS in the fall of 2007 there were many who claimed that it signaled the end of the PBX and that IP-PBX vendors such as Cisco, Avaya, Nortel, NEC, Siemens, Mitel and others would be seriously impacted by Microsoft's entry into the VoIP market. OCS does have VoIP capabilities, but for most medium to large enterprise, the product's native telephony features and functionally is inadequate. OCS can integrate with IP-PBXs to provide the telephony requirements necessary for business. However, the integration is not elegant (in most cases it must be done via media gateways) and other than basic telephony features such as call origination and transfer, the bulk of the enterprise telephony functionality will be provided by the PBX; not OCS.

What follows is a partial list of telephony features and functionality required (or expected) by most medium and large enterprise that are not available from a standalone OCS solution:

E911

E911(as a telephony feature) refers to the ability of a telephony system to accurately identify the location of the 911 caller and to accurately deliver that information to the correct emergency dispatch location. That can be tricky in the world of IP Telephony since IP Phones can easily be moved from one location to another. However, there are proven and reliable ways to address the challenge. While there are a variety of approaches, all major IP Telephony vendors have E911 functionality natively or have integrated 3rd party products into their solutions.

In some cases, it is acceptable to have one or more analogue circuits to provide E911 functionality. Also, an IP-PBX system installed in a small office may not require E911 functionality if it is connected to the PSTN directly since the telephone company would take care of the 911 location and routing functionality.

However, in any large enterprise environment, E911 functionality is mandatory. I've heard the argument that whether E911 functionality is required or not is based on regulatory requirements for the location in question: nonsense! A telephony architect or implementer has a moral responsibility to ensure that a caller can place an emergency call when needed and that the call will be routed to the correct location with the correct information.

SIP Trunking

IP Trunking, commonly referred to as SIP Trunking (since SIP has become the de facto signaling protocol), is a relatively new method of connecting IP Telephony systems to the PSTN. Traditionally, and still the most common approach, IP Telephony systems are connected to the PSTN via Media Gateways. These devices also known as IP Gateways, PSTN Gateways or VoIP Gateways, convert VoIP from the IP Telephony system to ISDN or analogue circuits from the PSTN.

IP Trunking has many advantages, over the gateway approach including the fact that it can improve the quality of voice calls by reducing, or eliminating, conversions from one audio encapsulation method to another. Other advantages are cost, eliminating points of failure, maintenance and other advantages which I have listed in one of my previous articles on the subject.

Remote Survivability

Remote Survivability refers to the ability of a site, geographically separated from centralized call control or PSTN connectivity or both, to remain functional even if the site becomes isolated from the rest of the telephony system. For example, if the network link between a branch office and the IP-PBX, located at a company's head office is severed, the branch office may have a requirement for telephony services to remain functional. The level of required functionality will be dictated by the business requirements. IP-PBX vendors use a variety of methods to provide remote survivability to their IP Telephony solutions which involves distributing some, or all call processing functionality and PSTN connectivity.

Music on Hold

Most enterprises expect their telephony systems to play music, or some other source of audio, to callers when placed on hold or when a call is transferred. It is a basic functional component of any legacy or IP-PBX. In fact, most enterprise systems support Music on Hold from a variety of sources and in some cases, custom audio announcements whose content may be based on geographic location or other criteria.

Hunt Groups

A common feature of a PBX is the ability to have incoming calls directed to a queue where calls will be answered by agents based on a variety of criteria including but not limited to first available agent, least busy agent, round robin and others.

Attendant Console

While becoming less popular, many organizations still require that a live person process all incoming calls for an organization or an enterprise department. An Attendant Console will usually support many incoming calls and will provide the attendant with visual and audio prompts and queues to aid in the efficient processing of calls.

Admission Control

Admission Control allows a telephony system to refuse call attempts or to redirect calls when it detects that insufficient network resources are available to provide a quality voice path. I've heard Microsoft representatives make claims that Call Admission Control is not required, but for the reasons discussed in this previous article, I disagree.

Standards

One of the benefits IP Telephony systems is that many vendors support industry standards such as SIP for signaling, and CODECS such as G.711 and G.729. While not perfect, interoperability among vendors has been steadily improving for the last several years. As a result it is now possible, for example to install an IP-PBX from one vendor and select lower cost IP Phones from a different vendor. Not so with Microsoft since they have chosen to implement their own spin on SIP and have chosen their own proprietary CODEC called RTAudio. To date, the only supported OCS phones are a model by Nortel/LG and a model by Polycom. Neither phone supports LLDP-MED, a link discovery protocol that can play an important role with respect to VLAN, DHCP and Power over Ethernet configuration. The proprietary nature of the product also excludes the possibility of using 3rd party softphones such as the very popular X-Lite.

Geographic Diversity

A benefit for many large organizations deploying IP Telephony is that the any-to-any nature of IP networks allows IP Telephony systems to be designed with a high degree of redundancy by separating the call control functions geographically. The business continuity benefits of such architecture can be very compelling. OCS does not support geographic diversity.

Conclusion

I remember when Cisco first got into the telephony market approximately 10 years ago. Relative to the features and functionality available from TDM-based PBXs (not to mention service quality and reliability), their product had minimal functionality. As a result, it took many years of product development for their IP Telephony product to move beyond the early adopters and into the mainstream marketplace we see today.

Microsoft will, I am confident, continually improve their telephony capabilities, but like Cisco, it won't happen overnight. Meanwhile, the IP-PBX will remain alive and well for quite some time. And while Microsoft adds telephony features to OCS, the PBX vendors will continue to evolve and improve their own products; both from a telephony and an overall UC perspective.

The PBX is alive and well. And while it will continue to evolve, the PBX and its leading vendors won't be disappearing any time soon.
 
Rick McCharles
Unified Communications Practice Principal
RIC Services, Toronto, Ontario Canada

Stumble It!

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 McCharles
Unified Communications Practice Principal
RIC Services, Toronto, Ontario, Canada
Stumble It!

Found this quite amusing. Nice to see the lighter / human side of Bill.


Stumble It!

Despite all of the media hype, Unified Communications is not a new 2007 technology. The term Unified Communications has became a popular way of describing the continuing evolution of communications technology. An evolution enabled mostly by IP and related protocols and devices.

Many of the Unified Communications products that have emerged this past year were not new at all. Rather, in many instances the new products were nothing more than branding changes to an existing product line. This re-branding of an existing technology reminds me of a similar change that occurred in the mid 1990s. At that time, multi-port Ethernet bridges suddenly morphed into Layer 2 switches. Despite the widespread perception, there was nothing dramatically different between bridges and switches. At the time, I worked for Digital Equipment Corporation (DEC) and many of our customers and DEC sales representatives were concerned that we were missing the boat since we didn’t manufacture switches. Fortunately, DEC marketing was able to address this product gap literally overnight by renaming the DECbridge product to the DECswitch. And voila, we were in the switching game!

Microsoft’s release of OCS 2007 accelerated the awareness of the benefits of unifying communication services and devices but in my view, Unified Communications is simply the continuing evolution of IP Communications that was enabled by VoIP during the late 1990s; which later enabled IP PBXs and IP Telephony.  In fact, many of the attributes, devices and functionality attributed to Unified Communications are not new at all.  USB handsets, Softphones, Presence / Status / Availability, IM and Simultaneous Ring were all part of the Hosted IP Telephony services that I was helping Telus to develop in 2002.

So, despite what many marketing organizations would like us to believe, Unified Communications is not a new concept, nor is it a dramatic new technology breakthrough. I’m fine with calling the current state of IP Communications, Unified Communications. I’m reasonably confident that within a year or two, the term UC will be replaced with a new term that suggests something dramatically new.

With that little rant out of the way, what is Unified Communications and is there a succinct and accurate definition? I’ve seen many noble attempts to define UC, but I don’t like any of them. Most definitions are several sentences (or paragraphs) long and usually include multi modes, multi media, any device, any time, presence, filtering, availability, people, processes, applications, messaging, blah, blah.

The challenge is that most definitions are attempting to describe a concept or a point in time in the evolution of IP Communications. One can implement some aspects of UC, but saying that “we are implementing Unified Communications” is meaningless. It would be like saying “we are implementing Information Technology”.

So, here is my humble and likely inadequate definition of Unified Communications:

Unified Communications is part of the continuing evolution of IP Communications technology which automates and unifies all forms of human and device communications in context and with a common experience.

I welcome your suggestions for a better definition of Unified Communications providing it is less than three sentences!

Rick McCharles, IP Communications Consultant
RIC Services

Stumble It!

Stumble It!

Stumble It!

  Stumble It!

Tom Keating has written an excellent and informative review of Microsoft Office Communications Server 2007 (OCS). I encourage you to have a read.

Despite all the hype, Unified Communications is not a Microsoft invention and many of the services offered by OCS have been available from other vendors for quite some time. So too has the concept of IP Telephony and IP Communications, of all forms, being based on software platforms. Leading vendors such as Cisco, Avaya, Mitel and Siemens are not going to disappear just because Microsoft is in the game.

That being said, there is no doubt that Microsoft will have a significant impact. Their entry will also likely accelerate the integration of communications into business applications and processes. Integrators, equipment vendors, service providers and industry consultants must recognize the transition up the value chain. In three years from now, those who did not successfully adapt either will be out of business or relegated to the low margin "plumbing" aspects of IP Communications.

Rick McCharles
President
RIC Services Stumble It!