This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
1. - Understanding IP telephony and VoIP: Read more in this section
Explore other sections in this guide:
IP telephony infrastructure solutions vary widely among vendors, but they all share core functionality and architecture design approaches that are important to understand when integrating unified communications solutions.
Traditional PBX systems were isolated from the data network and from other voice systems within the organization. Phone switches connected directly to desk sets and required a separate nest of cabling to hook everything together. Moving to IP and network-based telephony unifies voice and data on a common infrastructure, not only eliminating extra cable runs throughout an office building but opening the door to a level of integration not usually possible on dedicated voice systems.
Centralized client/server IP telephony architecture
By its very nature, IP telephony takes a client/server approach to its architecture. The clients can be a mix of physical desk sets, mobile clients and computer-based softphones, as well as the IP telephony gateways that enable both remote site and telecom connectivity, ultimately connecting back to centralized call control and routing servers.
The shift to a centralized architecture for IP telephony (IPT) is a logical one for a number of reasons. First, a centralized architecture aligns the telephony solution with the rest of the enterprise network and applications.
"The centralization of call control and gateway services follows the data center-centric model popular for most enterprise-wide applications in which servers are housed in facilities capable of meeting high-availability requirements for survivability and availability," wrote Mark Cortner, senior analyst for Burton Group Network and Telecom Strategies, in a recent report, Enterprise IP Telephony Infrastructure: Evaluation Criteria.
As a result, enterprise communications are treated as a single entity rather than a group of discrete telephone systems. What's more, the architecture "supports capabilities such as enterprise-wide dial plans and integration with other communications and collaboration applications," Cortner noted. Enterprises can leverage a centralized IP telephony solution to gain optimized least-cost routing for calls, extension dialing between locations, and the ability to mobilize enterprise users.
In addition, because the IP telephony server is housed in the data center with cooling and power requirements taken into consideration, it is much better protected than a typical PBX housed in a wiring closet at a remote site.
Finally, a centralized IP telephony architecture can reduce the physical footprint of telecom equipment required at remote sites.
"The only enterprise IPT system components required for remote locations are remote gateways that provide access to and from the public switched telephone network (PSTN)," Cortner wrote. This simplifies branch office deployments and brings the core of the IPT solution closer to the support teams in the data center, improving response time and reducing the time needed to troubleshoot problems.
IP telephony and service-oriented architecture
A main business driver for transitioning from a traditional circuit-based PBX solution to packet-based IP telephony services is integration of enterprise communication with business processes and applications, and capture of information about every point of contact using the system. Ultimately this information is used to enable technologies such as presence and chat. To that end, Cortner suggests that enterprises determine the level of service-oriented architecture (SOA) of any IP telephony solution being evaluated.
"The SOA-based platform will facilitate the extension of communications activities and information to business processes, which are commonly known as communications-enabled business processes (CEBP)," Cortner wrote.
Compliance with SOA standards will enable the integration of IP telephony services with these business processes; so, for example, a CRM package can communicate with the IPT to collect information about customer calls and enable a salesperson to initiate a phone call to a customer within the CRM application. Applying SOA enables a standardized approach to integration and the details of initiating and terminating communication sessions within the application.
Availability and redundancy for IP telephony systems
There is a general expectation in telephony that when a user picks up a handset there will be dialtone (including access to emergency services) and that customers will always be able to call into the organization. For that reason, 99.999% uptime is a business requirement. Unfortunately, Ethernet and IP networks are deemed "best effort" networks. To compensate for this, availability and resiliency have to be factored in to every design decision during the transition to packet-based telephony solutions. A so-called five-9s of availability requires ensuring that remote sites have local dialtone available in the event of an enterprise WAN outage. That means both the enterprise network and WAN teams must jointly decide quality of service, prioritization, and bandwidth requirements necessary for the IP telephony architecture to be integrated into the broader enterprise network.
Redundancy is central to achieving this level of availability. Cortner's report suggests a minimum of active/passive redundancy, with a preference for a load-sharing approach. Active/passive redundancy defines one component as primary for its function, with a matched secondary component that is available for switch-over in the event that the primary component fails. A load-sharing approach goes a step further, however. In this form of redundancy, both components are active, taking a portion of the work to process. In the event one of these components fails, the other can assume the additional workload. The load-sharing approach not only eliminates the single point of failure for its role, it also allows the IP telephony architecture to scale to meet the needs of a growing enterprise.