Results tagged “ip pbx” from IP Communications and Technology

OCS Does Not Signal the Death of the PBX

| | Comments (0)

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

StumbleUpon ToolbarStumble It! Add to Technorati Favorites

Unified Communications Defined

| | Comments (0) | TrackBacks (1)

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


StumbleUpon ToolbarStumble It! Add to Technorati Favorites

IP-Centrex or IP-PBX

| | Comments (0)
Choosing a Service Delivery Model / IP-Centrex vs. IP-PBX

(Part 3 of a 6 Part Series)

Part 1 of this series provided some tips to help you create a solid and credible business justification for an IP Telephony migration. Part 2 focused on the Human Factor of an IP Telephony implementation. Part 3 of this series will provide some guidance to assist you in choosing between a Premise-based or Hosted IP Telephony solution.

For the purpose of clarity, the following terms and definitions will be used in this article:

IP-PBX:

A premise based IP Telephony solution. Most or all of the components of the solution are located at the customer premise. The components are usually purchased by the organization. The product is usually designed to serve a single company. In some instances, a vendor may own and manage the IP-PBX as part of a managed service.

IP-Centrex:

Similar to regular Centrex, an IP-Centrex solution is hosted by a service provider. The components that deliver the service are designed to serve hundreds or thousands of customers. With the exception of telephones (which are located at the client), most of the functional components are located in a secure environment at the service provider’s location.

IP-Centrex or IP-PBX ?

The first question that should be answered is whether your organization will even consider outsourcing a vital service such as voice communication services. For some organizations, corporate policy or culture will not permit outsourcing services that are considered mission-critical. In those cases, the choice is clear: IP-PBX.

What follows is high-level comparison of the two service delivery models. It should be noted that the comparisons are not absolute. There are of course exceptions and the suitability of the service type will be dependent on the particular circumstances within your organization.


IP-Centrex

IP-PBX

Service Availability

IP-Centrex service availability is limited in North America. In some locations, IP-Centrex is not available at all. The ILECs (Incumbent Local Exchange Carriers) have, to date, been reluctant to deploy IP-Centrex services within their own territories. That will change over time, but today competition in IP-Centrex services is limited.


Small vs. Large Business

IP-Centrex services are best suited for small to medium organizations (10 to 200) users. IP-Centrex can offer a rich set of features and functionality that small organizations cannot typically afford to build on their own. In addition, many small companies lack the staff and expertise to implement IP Telephony on their own.

IP-PBX solutions are available for the smallest to largest organizations.

Capital vs. Operational Expenditures

IP-Centrex will require less initial capital expenditures and may offer more predictable operational spending. However, typically the two most costly factors in an IP Telephony solution are network upgrades and telephones. These two elements may necessitate a significant initial capital investment. A service provider may be willing to bundle these costs into the monthly fee. Operations of the internal infrastructure may also result in increased operational expenses above the recurring cost of the service.

An IP-PBX is subject to the same potential costly network upgrade costs as IP-Centrex. These, and all other solution costs, will require a greater initial investment than IP-Centrex.

Operational costs should be lower than IP-Centrex but these may be more difficult to predict and control.

Customization

In general, service providers build their solutions so that they can be reliably replicated, delivered and managed across their customer base. This is important since customization for thousands of customers could result in an operation that would be impractical to manage and operate. Your organization will likely be limited to a specific set of features and products that are predefined in the IP-Centrex service. This may result in less flexibility and ability to adapt to new business requirements. I am not aware of an IP-Centrex solution that offers an API to individual end-customers.

IP-PBX solutions will offer more customization options. In addition, an IP-PBX solution may have APIs that allow the integration with external business processes and applications.

Company Staff, Expertise and History

Organizations that are currently Centrex customers may not have the experience required to install and operate an IP-PBX solution. However, it is important to note, that unless you also outsource the network infrastructure, your company will still be required to manage and operate the infrastructure required to deliver the IP-Centrex service within your organization.

Designing, installing and operating an IP-PBX solution requires skills not typically found in either Telecom or IT. An IP-PBX solution will necessitate associated training and may require the use of external expertise during the design, implementation and early stages of operations.

E911

Enhanced 911 capabilities vary among service providers. Most will be able to deal effectively with locations that are directly connected to the IP-Centrex service. However, if your organization has other locations where IP-Centrex is being delivered across your network from a central service-provider connection point, the IP-Centrex solution may not be able to identify the location of the 911 caller.

Enterprise-class IP-PBX solutions from the major vendors can be engineered to provide reliable E911 services to users located within a predefined geographic network boundary.

Integrated Applications

Integrated applications such as Call Centres, Instant Messaging, Presence and Meet-Me Conferencing may not be available from an IP-Centrex based solution. Additional monthly or usage charges may apply if these types of services are available.

Integrated applications are available with IP-PBX solutions. They may be included in the core software or they may require a one-time purchase and follow up maintenance charges.

Admission Control

Unless the IP-Centrex solution supports RSVP (I’m not aware of any that do so) it will likely be unaware of bandwidth utilization conditions inside your network and will therefore be incapable of rejecting a call attempt, even if insufficient network resources are available to support the call.

Some IP-PBX vendor solutions incorporate devices distributed at key locations within your network or support RSVP to allow the system to determine if sufficient network resources exist to allow a call and ensure voice quality.

Disaster Recovery & Survivability

With a typical IP-Centrex solution, if part or all of your organization’s network was non-functional, incoming calls could still be handled by the IP-Centrex system, in a couple of different ways:

  1. When the system detects that the destination (IP Telephone) is not available, the system could direct the call to the service’s hosted voicemail system.
  2. The system could redirect calls to devices or locations that are still available. For example, calls could be redirected to an employee’s home phone, cell phone or an alternative functional location.

The circuit connection(s) from your organization’s data network to the service provider can potentially be a single point of failure. The survivability aspects already discussed, and the addition of redundant circuits and components, can mitigate the risk.

Some IP-PBX solutions can compensate (at least partially) for data network circuit failures with some form of local (on-site) backup systems. At a minimum, these backup systems will allow extension-to-extension calling and will allow outgoing calls, including 911 calls.

Distributed call control and PSTN connectivity or additional data network redundancy can mitigate the risk.

Primary call control system failure would result in the inability to process incoming calls unless some form of alternate call routing had been previously arranged with the telephone company. It would also be necessary for the associated supporting systems and processes to have been in place prior to the failure event.


Important considerations if you choose an IP-Centrex solution:

  • Ensure that the service provider is financially stable and that you trust them to provide a reliable service over the long term.
  • Negotiate an acceptable SLA (Service Level Agreement) and be satisfied that they are capable of meeting their obligations. (A monetary credit will likely be inadequate compensation for poor or unreliable service)
  • Attain a service commitment for the term of the contract and a “not-to-exceed” increase upon renewal.
  • Ensure that the service can scale to accommodate your expected growth.

Conclusion

In general, IP-Centrex service is best suited for small to medium business. Large organizations will typically require more functionality, customization and service control than is available from IP-Centrex. Hybrid models that combine IP-PBX and IP-Centrex may be a viable model. For example, large organizations with many geographic locations may choose an IP-PBX for larger buildings and IP-Centrex for remote and lower user-density branch locations.

RIC has extensive experience with both service models from both the service provider and enterprise perspectives and we can assist you in determining what is best suited for your organization.

Rick McCharles
www.ric.ca

StumbleUpon ToolbarStumble It! Add to Technorati Favorites

Asterisk Becomes An Appliance

| | Comments (0)
Asterisk, is an Open Source IP PBX in software. It runs on a wide variety of operating systems including Linux, Mac OSX, OpenBSD, FreeBSD and Sun Solaris.

While Asterisk has been available for several years, getting a working system configured was somewhat challenging for folks with limited technical abilities or those not comfortable in the Linux environment. While Asterisk seemed interesting, for many, the learning curve seemed too challenging. As a result, Asterisk has not had much of an impact on mainstream IP Telephony. AsteriskNOW may change that fact in a significant way.

As described on the AsteriskNOW website:


AsteriskNOW™ is a Software Appliance; a customized Linux distribution that includes Asterisk®, the Asterisk GUI, and all other software needed for an Asterisk® system. The most popular open source IP PBX software, Asterisk®, can now be easily configured with a graphical interface. AsteriskNOW™ includes all the Linux components necessary to run, debug and build Asterisk®, and only those components, so installation is easy. You no longer have to worry about kernel versions and package dependencies. Unlike other Linux distributions used to deploy Asterisk, no unnecessary components that might compromise security or performance are included.”

Yesterday, I downloaded the Beta 2 release from http://www.asterisknow.org/downloads and had a working configuration up and running in about 30 minutes. It was quite easy to setup and Linux knowledge was not required.

While it is apparent that many configuration parameters still require use of the command line interface, I’m convinced that the GUI combined with the “Appliance-like” model will cause many non-geeks to notice the functionality that Asterisk delivers and will lead to its accelerated deployment in mainstream IP Telephony.

StumbleUpon ToolbarStumble It! Add to Technorati Favorites

Implications of VoIP Growth Projections

| | Comments (0)

According to Osterman Research, 45% of U.S. business and organizations will be using VoIP by the end of 2007. Jupiter Research reports that 12.1 million U.S. households will be using VoIP.

I’m a little skeptical of these forecasts but even if the actual numbers are only half of the projections there are serious implications.

Implications for Enterprise

If you’re responsible for your organization’s voice services and you haven’t given IP Telephony any thought, the time is now. At the very least, you should understand the drivers behind the technology shift and the potential implications to your business. Media hype aside, sooner or later, IP Telephony will be part of your voice communications and you should at least have a high level plan and timeframe on how you will make the transition. Often, a preliminary investigation will reveal surprising cost and competitive advantages to making the transition much sooner than you may have anticipated.

Implications for Regulators and Service Providers

The tremendous growth of residential VoIP services should instill a sense of urgency with regulators and service providers to address many of the technical issues that have not yet been adequately addressed:


  • E911 Services

  • Routing the emergency call to the correct location

  • Preventing a caller from disconnecting the call

  • Ability of emergency personnel to call back

  • Quality of Service

  • Having the 911 routing issue solved won’t help if the non-QoS enabled network connection is so congested that the voice is unintelligible

  • Emergency issues aside, customers will demand consistent voice quality

  • Power Protection

  • Unlike PBX systems that usually have very limited battery backup protection, residential POTS services will continue to function for days and longer. Today’s residential VoIP services don’t even come close to replicating this level of availability.


Rick McCharles
www.ric.ca
StumbleUpon ToolbarStumble It! Add to Technorati Favorites
About Me

Tags

My Links