Survivability in IP Centrex and Distributed IP-PBX Environments. August 08

Transcription

1 Survivability in IP Centrex and Distributed IP-PBX Environments August 08

2 Table of Contents Introduction 3 The Survivability Challenge Overcoming the Single Point of Failure trap 4 IP-Centrex and Distributed IP-PBX Survivability How it works? 5 Internal office VoIP communication survivability 5 External office communication survivability 5 Recovery from network failure 5 Delving into technical details 6 Implementing an Active SAS mechanism 6 Implementing a Passive SAS mechanism 7 Active mode vs. Passive mode Pros and Cons 9 The Five Star Approach 9 Standards Based SAS Implementation 9 Scalable Solution - Growing with your Enterprise 9 Redundancy Mechanism for Survivability Applications 10 Advanced Support for Emergency Calls (e.g. 911) 10 Maintain Maximum Functionality Level in Emergency Mode 10 About AudioCodes Mediant 1000 Multi Service Business Gateway (MSBG) 10 AudioCodes Stand Alone Survivability powered by the Mediant MSBG 10 About AudioCodes 11

3 Introduction With the evolution of the VoIP market, IP Centrex services and IP-PBX applications have evolved to become two of the predominant offers for enterprises of all sizes. This market trend is driven by the well known cost-effectiveness of IP-based solutions which steadily provides a richer set of features and functionalities to end users, whereas traditional PBX s and legacy telephony are lagging way behind. This innovative technology creates new challenges which may be perceived as significant drawbacks by end users. This document discusses one of the main challenges that should be meticulously addressed - the survivability problem of the IP Centrex and distributed IP-PBX architectures, which are an outcome of the inherent dependency of the entire enterprise telephony system on a single central server. This document also presents the Five Star Approach - five fundamental guidelines and capabilities that the enterprise IT manager should require from its IP-Centrex / IP-PBX service provider for ensuring survivability and creating a reliable IP-based telephony network with comparable or even superior survivability features than the legacy telephony network (PSTN). In order to have a better understanding of these challenges, let us start with a brief definition of the services themselves. IP Centrex (Central Exchange) like the traditional Centrex, IP Centrex is a solution hosted by telecommunication service providers which includes call control and service logic functionalities. Unlike the IP-PBX solution, the customer does not own the IP Centrex servers which are located on the service provider s premises. The IP Centrex solution is best suited for small-medium enterprises that typically lack internal staff and expertise for maintaining the features and capabilities offered by this service. Figure 1 - Typical IP Centrex Topology N IP-PBX The IP-PBX is a customer premise-based VoIP solution where all the solution s logic and components are self owned by the customer. IP-PBX is a suitable solution for the medium to large enterprise telecommunication requirements. Distributed IP-PBX is an architecture by which the enterprise locates a central IP-PBX server in its headquarters and provides telephony services to its distributed branches. Figure 2 - Typical Distributed IP-PBX Topology N 3

4 Stand Alone Survivability (SAS) An application agent which is installed in the enterprise headquarters and/or branch office premises to ensure continuous telephony service during network outage scenarios such as WAN failure, thus preventing communication with the central server. To ensure full coverage of telephony services during a network failure, a SAS agent should be installed in each one of the enterprise offices. The Survivability Challenge Overcoming the Single Point of Failure trap This section describes the motivation behind the enterprise survivability requirements for IP Centrex and IP-PBX services. The traditional telephony service, based on the legacy PSTN network, has placed high standards of stability, survivability and sustainability capabilities throughout more than 100 years of operation. The same level of service survivability is typically expected from any IP-based solution. Allegedly one of the major barriers towards achieving this goal is the IP Centrex and Distributed IP-PBX s unique deployment architecture which inherently includes components that potentially might become a single point of failure. In simple terms, any single piece of equipment experiencing a failure event can bring the entire telephony service operation to a halt. Both IP Centrex and IP-PBX topologies suffer from a number of such potential single points of failure. Typically the IP Centrex and IP-PBX servers are typically the only components in the network that maintain the entire telephony system topology structure. These servers register all the IP-Phones and Media Gateways in the network; maintain a complete and updated snapshot of the telephony network and manage the call control by addressing calls to and from enterprise phones, based on an internal routing database. In case of failure in the IP Centrex or IP-PBX servers, the enterprise will lose its internal telephony service at any branch, between its offices, as well as with the external environment. In fact the enterprise loses its main communication tool and all contact with the external environment, rendering it useless. A similar crisis may occur in the case of failure in the corporate WAN and problems with an access device such as the DSL modem. The enterprise will lose its connection with the IP Centrex or the IP-PBX and as a result, enterprise telephony capabilities will become unavailable. Additionally, one of the worst consequences of a breakdown in telephony services is the inability to generate emergency calls (e.g. 911), since this type of dialling requires a PSTN breakout which is located in the central office where the IP-PBX or IP Centrex server is located. During a failure scenario, this connection is lost. This issue must be carefully resolved before replacing the traditional telephony network with IP-based telephony technology. Figure 3 - Single Point of Failure in IP Centrex Environment N 4

5 IP Centrex and Distributed IP-PBX Survivability How does it works? This section will describe a high level view about the technical aspects of a typical SAS application. Internal Office VoIP Communication Survivability As previously described in this paper, the IP Centrex or IP-PBX applications keeps an updated snapshot of the network structure and solely controls the telephony in the enterprise. In order to terminate this monopoly and protect against the single point of failure, SAS agents are installed in each one of the enterprise offices which are served by the remote IP Centrex or IP-PBX. The SAS agent acts as an outbound Proxy and Registrar which registers all IP-Phones and Media Gateways in the network and simultaneously transfers the registration transactions to the main IP Centrex or IP-PBX server. This behaviour ensures automatic redundant registration for all telephony devices in the office network since the SAS agent maintains a complete and updated copy of the telephony network structure. Taking advantage of this capability, in the case of central server failure, the SAS agent assumes the lead to handle all call controls within the protected enterprise branch. External Office Communications Survivability Once the intra-branch telephony connection failure is overcome, we can analyze how the SAS agent handles the inter-branch connectivity and connectivity with the external world during IP Centrex or centralized IP-PBX failure. To answer this challenge, the SAS agent should be equipped with an integrated fallback mechanism to the local legacy PSTN network. Using this feature, once the SAS agent observes a connectivity problem with the central IP Centrex / IP-PBX server (indicated by a loss of connection with this server), it automatically redirects all the outbound calls towards the PSTN network and begins forwarding inbound calls from PSTN lines to telephone devices in the office. Utilizing its integrated fallback mechanism, the SAS agent maintains complete call control and media connectivity to and from the external telephony network. Recovery from Network Failure During the emergency operation mode, the SAS agent should constantly monitor the network connectivity and once the connections with the IP Centrex / IP-PBX server are resumed, it will switch back to the normal mode, whereby control is provided by the IP Centrex / IP-PBX servers. Figure 4 - IP Centrex Application 3 N 5

6 Figure 5 - Distributed IP-PBX Application In case of failure in one of the network elements, the SAS agent will take the lead and handle all the intra-call control management as well as the external (PSTN) call control and media connectivity via a built-in fallback mechanism. Delving into technical details This section will describe in more detail the technical aspects of the solutions suggested previously, assuming the solution s implementation is based on SIP (Session Initiation Protocol), therefore basic understanding of this control protocol is recommended. Readers who do not want to dive into the technical aspects of this implementation may skip to the next section: The Five Star Approach. There are two main alternative implementations for the SAS application: the active and passive models. Implementing an Active SAS mechanism IP-Phone Configuration For the sake of SAS implementation, the primary proxy server (S1) for the IP-Phone is the SAS agent while the IP Centrex or IP-PBX is defined as the secondary proxy server (S2). IP-Phones should be able to automatically switch between the primary server (SAS agent), and the secondary server (IP Centrex/ IP-PBX server) in the case of failure. It is also expected to switch back to the original configuration when connection and service are restored. Active SAS Mechanism during a Normal Operation Mode The installed SAS agent acts as an outbound Proxy and Registrar which registers all IP-Phones and Media Gateways in the network, and simultaneously transfers these registrations to the central IP Centrex / IP-PBX server. In fact, all IP-Phones are first registered with the SAS agent and only later the SAS agent registers them with the IP Centrex / IP-PBX server. This process ensures automatic redundant registration for all the telephony devices in the enterprise network - since the SAS agent maintains a full and updated copy of the telephony network structure. The Call Setup and Call Termination messages are sent first to the SAS agent which transfers them automatically to IP-Centrex / IP-PBX and vice versa 1. On the other hand, the media session is established directly between the IP Centrex / IP-PBX server and the IP-Phones, bypassing the SAS application and avoiding a traffic bottle-neck. During normal operation mode, when the IP Centrex / IP-PBX is available and provides telephony services, the SAS application should constantly monitor the IP Centrex / IP-PBX availability using Standard SIP messages. Simultaneously, IP-Phones should monitor the SAS agent s (S1) availability and be able to switch to their secondary server (S2) which has been predefined as the IP Centrex / IP-PBX server. This double monitoring ensures that the SAS agent will not become a single point of failure since the IP-Phone will detect its failure and switch automatically to the IP Centrex / IP-PBX servers when needed. 1 This is the most common architecture; however other implementations are valid as well. For example in some SAS implementations all the call control messages are directly being transmitted by the IP Centrex / IP-PBX directly to the IP-Phone, actually bypassing the SAS server in non-emergency operation mode. 6

7 Active SAS Mechanism during Emergency Operation Mode Once the SAS agent detects a communications failure with the IP Centrex / IP-PBX server, it switches into an emergency mode. During this emergency mode the SAS agent assumes the lead and handles all call setup and termination inside the enterprise as well as handling the connectivity with the external environment via its integrated PSTN fallback mechanism (analog or digital). Usually, the level of the telephony services provided by the SAS agent is limited and mostly includes basic call flows. During the emergency mode, the SAS agent constantly monitors the network connectivity with the IP Centrex / IP-PBX and once the connection resumes, it switches back to the normal mode in which control is provided by the IP Centrex / IP-PBX servers. Figure 6 - Active SAS Implementation Model Implementing a Passive SAS Mechanism IP-Phone Configuration Like the Active Implementation model, the Passive model also assumes that IP-Phones in the enterprise support automatic switching between alternative proxy servers, in the case of a failure in one of these devices. However, in the passive model, the primary proxy server (S1) for the IP-Phone is the IP Centrex / IP-PBX while the SAS agent is defined as the secondary proxy server (S2). This means that IP-Phones should be able to switch between the primary server (IP Centrex / IP-PBX), and the secondary server (SAS) in the case of a failure. Once again - it is also expected to switch back to the original configuration when the service is restored. 7

8 Passive SAS Mechanism during Normal Operation Mode In the passive implementation model the SAS agent is not involved in the call control for the duration of the normal operation mode. Registrations as well as other Call Control messages are sent directly from IP-Phones to the IP Centrex / IP-PBX and vice versa. Media sessions are also established directly between the IP Centrex / IP-PBX server and the IP-Phone, bypassing the SAS agent. During regular operational mode, IP-Phones should monitor the IP Centrex/IP-PBX server availability and have the ability to switch to their secondary server which is predefined as the SAS agent. Passive SAS Mechanism during Emergency Operation Mode Once the IP-Phone observes a communications failure with the IP Centrex / IP-PBX server, it switches to the SAS agent as a secondary proxy server and registers. This registration process is necessary since IP-Phones were not previously registered in the SAS agent. From this stage on, the SAS agent functions quite similarly to the Active SAS mechanism model. The SAS agent takes the lead and deals with all call control inside the enterprise as well as handling connectivity to the external environment by utilizing the integrated PSTN fallback capabilities (analog or digital). Once again, the level of the telephony services provided by the SAS agent is limited and mostly includes only basic call flows. Once the IP Centrex / IP-PBX becomes available again, the SAS agent automatically observes it and by using advanced SIP message manipulations, forces the IP-Phones to switch back to their primary server (S1) bypassing the SAS agent (S2). Figure 7 - Passive SAS Implementation Model 8

9 Active Mode vs. Passive Mode Pros and Cons The main advantage of the Passive mechanism model is its relatively high level of security compared to the Active mechanism model. In the Passive mechanism model during normal operational mode, the SAS agent is not involved in the message exchange; therefore fewer components are exposed to the network structure and call control messages. Generally there is a reduced risk of information snooping and eavesdropping. This is a critical feature for enterprises and institutes which are sensitive to these types of security threats and demand a maximum level of protection for their telephony network. The main drawback of this implementation model is the relatively long switch time between the normal and emergency operation modes. All IP-Phones must register with the SAS agent once entering the emergency mode, therefore might take some time until the SAS agent creates a complete picture of the telephony network in the office. Evidently, a quick switch time is the main advantage of the active SAS model. The Five Star Approach to Guidelines for Survivable IP-Centrex This section details AudioCodes Five Star Approach for survivable IP Centrex / IP-PBX services. Standards Based SAS Implementation Why shouldn t you redesign your network to support survivability? The primary requirement from any survivability mechanism is to be fully based on standard protocols such as the commonly used SIP to ensure the very basic level of integration within the customer s existing VoIP network. Implementing the SIP based survivability mechanism, guarantees interworking with many IP Centrex / IP-PBX servers as well as IP-Phones and VoIP Gateways. This certainly enables the customer to have the freedom to choose its VoIP implementation, components and service provider. Scalable Solution - Growing with your Enterprise Can your survivability application scale up with the rest of your telephony network? Looking ahead, enterprises should consider a possible expansion of their telephony network which will entail an extension of the survivability services. In order to protect their initial investment, the originally deployed survivability application should be designed as a scalable solution enabling expansion of its services in the future. Lack of these features will pressurize the customer to replace their original survivability equipment and re-invest in a new server with a higher performance level. An efficient, scalable solution should enable system upgrades either by means of software updates or the installation of an additional survivability application including the original one, thereby extending the number of protected users in an enterprise. 9

10 Redundancy Mechanism for Survivability Applications What happens if Murphy s Law strikes twice? What happens if the survivability application ceases while in emergency mode? This question can be addressed by deploying a redundant survivability application in customer premises. This redundancy mechanism should maintain telephony services in the event that one of the original survivability applications halts during an emergency scenario. Advanced Support for Emergency Calls (e.g. 911) Safety is paramount! The most elementary expectation from any survivability application is to enable emergency calls from enterprise headquarters or its remote branches. In addition, the survivability mechanism should be able to detect such calls and prioritize them accordingly, even if it means to tear down other regular calls. Prioritizing emergency calls is essential during emergency mode since occasionally survivability applications do not maintain the same voice session throughput as compared to the original IP-PBX or IP Centrex servers. Maintain Maximum Functionality Level in Emergency Mode Should we be content with basic call connectivity during emergency operational mode? Sometimes it is not enough to have just basic calls during emergency scenarios as other functionalities are required and may even be considered mandatory. For example, during normal operational mode, telephone numbers within the enterprise can be reached by dialling only their suffix extensions instead of dialling the complete number. These services are critical for the enterprise s normal telephony services and should be supported by the survivability application during network failure. About AudioCodes Mediant 1000 Multi-Service Business Gateway (MSBG) The Mediant 1000 MSBG is an all-in-one multi-service access solution for service providers offering managed services and distributed enterprises. This multi-service business gateway is designed to provide converged voice and data services for business customers at wire speed while maintaining SLA parameters and superior voice quality. The Mediant 1000 MSBG is a direct evolution of the field-proven and highly interoperable Mediant 1000 VoIP media gateway. This new and innovative product allows a rich variety of benefits for Service Providers, Business Customers, Original Equipment Manufacturers (OEM), and Value Added Services (VAS) developers. Along with its best-of-breed Media Gateway functionality, the Mediant 1000 MSBG provides Data Routing, WAN Access, and Session Border Controller (SBC) functionalities in a single cost-effective hardware platform. Utilizing its built-in Intel processor based server (the OSN), the Mediant 1000 MSBG can accommodate a variety of 3rd party applications such as IP-PBX, Call Center, Conferencing Server, Fax Termination application and more. Mediant 1000 MSBG AudioCodes Stand Alone Survivability powered by the Mediant 1000 MSBG In addition to the above features the Mediant 1000 MSBG provides advanced survivability services as part of the Stand Alone Survivability (SAS) feature, designed and developed particularly for the IP Centrex and IP-PBX environments. SAS is an application agent that is installed in an enterprise s headquarters and/or branch office premises to ensure continuous telephony service during network outage scenarios such as WAN failure, thus preventing communication with the central server. AudioCodes SAS adheres to the Five Star Approach guidelines, and provides reliable and continuous telephony services. For more information about the Mediant 1000 MSBG and the SAS feature, please visit: 10

11 About AudioCodes AudioCodes Ltd. (NasdaqGS: AUDC) provides innovative, reliable and cost-effective Voice over IP (VoIP) technology, Voice Network Products, and Value Added Applications to Service Providers, Enterprises, OEMs, Network Equipment Providers and System Integrators worldwide. AudioCodes provides a diverse range of flexible, comprehensive media gateway, and media processing enabling technologies based on VoIPerfect TM -- AudioCodes underlying, best-of-breed, core media architecture. The company is a market leader in VoIP equipment, focused on VoIP Media Gateway, Media Server, Session Border Controllers (SBC), Security Gateways and Value Added Application network products. AudioCodes has deployed tens of millions of media gateway and media server channels globally over the past ten years and is a key player in the emerging best-of-breed, IMS based, VoIP market. The Company is a VoIP technology leader focused on quality and interoperability, with a proven track record in product and network interoperability with industry leaders in the Service Provider and Enterprise space. AudioCodes Voice Network Products feature media gateway and media server platforms for packet-based applications in the converged, wireline, wireless, broadband access, cable, enhanced voice services, video, and Enterprise IP Telephony markets. AudioCodes headquarters and R&D are located in Israel with an additional R&D facility in the U.S. Other AudioCodes offices are located in Europe, India, the Far East, and Latin America. International Headquarters 1 Hayarden Street, Airport City Lod 70151, Israel Tel: Fax: AudioCodes Inc. 27 World s Fair Drive, Somerset, NJ Tel: Fax: Contact us: Website: AudioCodes Ltd. All rights reserved. AudioCodes, AC, Ardito, AudioCoded, NetCoder, TrunkPack, VoicePacketizer, MediaPack, Stretto, Mediant, VoIPerfect and IPmedia, OSN, Open Solutions Network, What s Inside Matters, Your Gateway To VoIP, 3GX, InTouch, CTI2, CTI Squared, Nuera and Netrake are trademarks or registered trademarks of AudioCodes Limited. All other products or trademarks are property of their respective owners. Ref # LTRM /08 V.1 11