How To Implement A Sip Trunking Service

Transcription

1 Technical white paper The benefits of centralized SIP trunking and best practices Enterprise focus Table of contents Introduction 2 What is centralized SIP trunking? 2 SIP trunking 2 Centralized SIP trunking 5 Considerations 8 SIP trunk service provider 8 Security 8 Enterprise LAN capacity 8 Manageability 9 Careful planning 9 Misconceptions 9 Phone (endpoint) replacement 9 Reliability 9 Centralized SIP trunking in different environments (cost savings and possible scenarios) 10 Enterprises with legacy PBXs 11 Enterprises with a mixture of legacy PBXs and a new VoIP solution (call agents) 12 Enterprises with only a VoIP solution and no legacy PBXs 12 Enterprises with legacy PBXs that implement a centralized VoIP solution and centralized SIP trunking 13 Best practices 13 HP Centralized SIP Trunking Service 13 Conclusion 14 Glossary of terms 14 For more information 15

2 Introduction Carrier Session Initiation Protocol (SIP) trunks have become a viable option to the enterprise in lieu of traditional public switched telephone network (PSTN) connectivity options, such as integrated services digital network (ISDN) primary rate interface (PRI)/basic rate interface (BRI) and T1/E1, especially in recent years. There are numerous benefits that SIP trunks bring to the enterprise. Further enhancing those benefits are methodologies that, when leveraged together with SIP trunks, help generate even more economies of scale in cost savings and efficiencies. Centralized SIP trunking is one of these methodologies, and it helps enterprises generate significant cost savings even as it helps build a foundation for Unified Communications (UC). This document explores the technology behind SIP trunks, the technology it replaces and why, the centralized SIP trunking approach, the features and robustness of centralized SIP trunking, considerations and misconceptions, and best practices that help maximize the business value of a centralized SIP trunking deployment. Next, the solution is explained as it applies to different scenarios, from an environment that consists primarily of legacy private branch exchanges (PBXs) through a mixed legacy PBX and Voice over Internet Protocol (VoIP) environment, and on to a modern VoIP environment. Finally, a few scenarios are examined to demonstrate the business benefits that may be achieved with the implementation of centralized SIP trunking and the proper framework. What is centralized SIP trunking? SIP trunking An explanation of SIP trunks is needed prior to describing the centralized SIP trunking approach. SIP is the premier modern communications protocol. It is based on an Internet Engineering Task Force (IETF) request for comments (RFC) that supports VoIP, instant messaging (IM), presence, video, etc. 1 Over the past few years, the SIP trunk has become a viable option for the enterprise. The term SIP trunk can mean different things to different people. It can refer to a SIP connection from one call agent to another over an enterprise network. Alternatively, it can also be a local area network (LAN) or wide area network (WAN), usually over a multi-protocol label switching (MPLS) network. (Call agent is the network component that switches a VoIP call. The term call agent will be used in this paper is also known as an Internet Protocol (IP) PBX, VoIP PBX, softswitch, and gateway controller.) In this type of SIP trunk, the carrier that connects the different enterprise branches does not provide SIP service directly, instead the SIP traffic is sent across the private WAN/MPLS network. The carrier just sees this SIP data as data on the MPLS network, it does not act on it, other than Quality of Service (QoS) actions. None of the carrier components terminate the SIP protocol in this case. To the enterprise, this SIP data is considered on-network. In this document, this type of SIP trunk will be referred to as an enterprise SIP trunk; figure 1 depicts such a SIP trunk. (Note that, in figure 1, VPN is a virtual private network a logical enterprise network that sits on public and private physical networks, allowing access only to enterprise interests. RTP is real-time transport protocol, the protocol that carries VoIP voice packets.) 1 Note that since SIP is still in RFC state, it has not yet been ratified to a standard. However, because of SIP s widespread use in the enterprise and carrier space for VoIP, a core suite of SIP has emerged, and with proper planning, a solution can be achieved to realize a modern UC foundation using SIP. One such solution is the SIP trunk. 2

3 Figure 1. Enterprise SIP trunk Another type of SIP trunk is the interconnection to other enterprise entities or the WAN/PSTN using a third-party (carrier) hosted SIP trunk. In this case, the data is considered to go off-network to the carrier SIP network, despite the destination being another enterprise branch or the WAN/PSTN. The carrier does terminate SIP protocol but acts on the SIP protocol. This type of hosted SIP trunk offered by carriers is termed carrier SIP trunk in this paper and is shown in figure 2. (Note, in figure 2, MGW stands for media gateway; also known, in carrier networks, as a trunking gateway. This device converts VoIP to PSTN protocol and voice traffic, and vice versa. TDM is time division multiplexing, a communications methodology that divides communications media into time slots to carry voice packets. It is the legacy transport used by legacy PBX for voice. Contrast TDM with RTP, which is used to carry VoIP voice packets. Finally, the softswitch is a carrier-class VoIP call agent typically capable of handling 100 to 200 calls per second; compared to an enterprise call agent, which typically handles two to five calls per second.) Figure 2. Carrier SIP trunk 3

4 Carrier SIP trunks are used in place of PSTN trunks. PSTN connections to a branch or data center include ISDN PRI connections, trunks (direct inward dial [DID], toll free), as well as T1/E1 connections. The ISDN PRI connection allows for 23 time slots (concurrent calls) or 30 time slots for E1-based connections. Current PRI and T1/E1 costs are based on full utilization of all time slots, whether or not they are actually being used. This is important because an organization typically pays for the full PRI or T1/E1 bandwidth, whether or not the resources are completely consumed. Fractional PRIs can be purchased as well, which reduces the unused capacity, but in most cases doesn t eliminate the overcapacity problem. With fractional PRIs, the costs are typically higher than a similar SIP trunk solution. A carrier SIP trunk is an IP-based alternative to PRIs and T1/E1s for communications (voice, IM, chat, presence, etc.) and connectivity into the branch and data center from the PSTN. Simply put, a carrier SIP trunk is an IP connection to the PSTN that utilizes the SIP protocol and IP transport mechanisms through the carrier WAN space. It extends the converged enterprise s network into the WAN via a hosted service. (Recall, an enterprise SIP trunk extends an enterprise into the WAN but is still part of the enterprise; it is considered to still be on-network from the SIP layer perspective.) For calls destined to the PSTN, a carrier SIP trunk is used for off-network access. For those off-network calls destined to a traditional phone over the PSTN, the carrier performs the integration of VoIP (SIP/RTP) to PSTN (SS7/QSIG/Q.931/TDM) on their network and then completes the call. SIP trunks have the following advantages over traditional PSTN connections using T1s, E1s, BRIs/PRIs, or trunks: More efficient More reliable More flexible Carrier SIP trunks are more efficient for an enterprise than legacy PSTN connections because of the pay-as-you-use model. PRIs are typically purchased in full-capacity or fraction-capacity bundles, in addition, expensive line cards or PSTN media gateways are required for PRIs. Carrier SIP trunks, on the other hand, can be incrementally purchased (released) as capacity scales up or down. First, there are two ways to look at reliability. One is from the perspective of downtime of the resource when calls are attempted. The other is from a blocking perspective where the resource is technically up and running, but is not available due to capacity constraints. Three different levels of reliability are typically used in the industry: % (high), 99.99% (normal), and 99.9% (standard). The first and most reliable of these is % (high), which equates to unexpected downtime of less than 6 minutes per year. Another way to look at % is from a resource blocking perspective. Again, blocking is a term used to describe what happens when all the given resources are up but are consumed; when the next call attempts to use the resources but none are available, the call is considered blocked. From a blocking perspective, to provide % reliability during busy hours, a majority of time sots/sessions/resources of the site population are needed. Next is 99.99% (normal), which translates to less than one hour of unexpected downtime per year. From a blocking perspective, 99.99% translates into a number of timeslots/sessions/resources equal to about half of the site population. Lastly, there is 99.9% (standard), which is less than nine hours of unexpected downtime annually. From a blocking perspective, standard reliability translates into a number of timeslots/sessions/resources equal to about one-third of the site population. (It is important to understand that designing from the downtime perspective is more common and typically results in less timeslots/sessions/resources than taking the blocking approach. With contact centers, the blocking approach is typically used.) Different sites may have different reliability requirements at the enterprise. The ratio of resources to population is heavily based on an enterprise s usage, reliability needs, and costs; typically it is anywhere from 10% to 80% of the site population, with the majority tending toward the lower end of the range (20 35%). With the correct IP architecture in place, all three reliability levels may be attained at different sites in the same enterprise. A network using carrier SIP trunks may be as reliable as or more reliable than one with PSTN connections (PRIs, BRIs, T1s, and E1s). There are several ways to achieve this. For example, to aid in the high reliability (99.999%) case, with a traditional phone network, an enterprise has to maintain two separate networks one for data and another for voice. One way to achieve high reliability (99.999%) is to deploy one fully redundant converged network (consisting of data and voice) that leverages two different carrier SIP trunk providers (for vendor redundancy and preferred last-mile redundancy). This is a very highly available solution and is, in general, cheaper than two separate networks for data and voice. One way to achieve normal reliability is to redundantly deploy critical devices, but not the full network. This, combined with SIP trunking, offers advantages over traditional PSTN connections for example, carrier SIP trunks can be provisioned to ring phones in multiple physical geographical locations with one phone number. If one site goes down, phone calls are still operational at the other sites. Also, voice and data can be routed quickly upon failure via different pathways to different enterprise sites. The carrier SIP trunk offers several benefits: SIP trunks can be provisioned to ring phones in multiple physical geographical locations with one phone number. Most services have long-distance calls with local calls included or significantly discounted because service fees are bypassed. Most SIP trunk packages include free calls between enterprise locations; inter-enterprise toll charges are eliminated (note that in countries such as India where toll bypass is not allowed, this may not be an option). 4

5 More cost-effective More features More leverage More responsive Since carrier SIP trunk services typically include reduced-price or free long-distance calls, those savings are typically gained by the enterprise. Additionally, because carrier SIP trunks can be provisioned as needed, the cost of unused PRI timeslots and the purchase of PRI line cards and/or media gateways is saved. Lastly, carrier SIP trunks extend the converged network into the WAN space, thus decreasing manageability costs. Carrier SIP trunks allow many different UC features to be transported across the carrier WAN. These include, but are not limited to, voice, video, presence (including rich presence), IM, and conferencing (including Web, audio, and video). Actual feature sets may vary between carriers. This benefit of carrier SIP trunks can be advantageous, especially when carrier diversity (having two different carriers provide the SIP trunks) is considered. When it is time to renew the contract with the carriers, because there are more carrier SIP trunk options available, having multiple links can provide leverage when bargaining for a new contract. The enterprise could route all traffic to one carrier or the other in an instant, as an example of how quickly a change could be made, and could then forgo any remaining toll charges to the carrier moved from. (Note: Ingress traffic is subject to the specific numbering and route patterns within the carrier, but egress traffic can be routed in an instant.) PRIs/BRIs and T1s are provisioned the old way, with long waits and methodical ordering and provisioning processes. Carrier SIP trunks, on the other hand, in addition to offering many more features and capabilities, are fast to provision and configure once the connections are initially set up. Once the trunk site is provisioned and the Session Border Controller (SBC) sized to expand, changes in capacity are quick. (Note that the SIP trunk and SBC should be sized to the growth of capacity changes in the nearer term and, in some cases, the longer term as well). When the enterprise needs to turn on a new feature, all it takes is a configuration change on a management graphical user interface (GUI). For example, if you want to enable presence through the carrier SIP trunk, it is instantly turned on. Also, if you need additional capacity and the SBC and SIP trunk service have the space, then all it takes is a simple configuration change to enable it. With most services, you still only pay for the SIP trunks that are in use. (Of course, performing due diligence to test that features will work across the enterprise and the carrier is still a best practice prior to turning on the feature.) Historically, carriers have used SS7 protocol for their core networks and interconnection to other carriers. Several have now converted their core to IP and SIP, and therefore now have a VoIP-based core. In fact, many calls traversing their networks, even though they may have originated as TDM calls, have been converted to VoIP and back again to TDM (depending on the destination) without the callers even knowing it. So, in fact, many users experience a VoIP call on a SIP core without even realizing it. As a result of having an IP/SIP core, expensive interconnect fees levied on the SS7 connections have been eliminated or significantly reduced (so that the carrier only has to interconnect on SS7 to legacy SS7 carrier networks). This helps the carriers offer a cheaper connection into the WAN for their customers, especially those with SIP trunks. The carriers have thus extended this offering of SIP out to the enterprise as an option to support the advanced communications features and demands of the enterprise. Carrier SIP trunks do not just carry voice but may carry all SIP-enabled communications (voice, IM, presence, video, , data, etc.). Again, support for these services varies by carrier. Centralized SIP trunking Centralized SIP trunking is an optimization of a distributed SIP trunking environment. It is one method of architecting for cloud services. It uses a combination of enterprise SIP trunks to maximize utilization of the enterprise network for on-net traffic, and it uses one or more carrier SIP trunks for centralized demarcation of calls destined off-net. Ingress calls to the enterprise enter at only a few core locations. The result is a further reduction in costs over standard SIP trunking or traditional trunking, where carrier demarcation occurs everywhere there is an enterprise site. Cost savings occur in the following ways: Decreasing or eliminating a carrier PSTN connection at each remote location reduces or eliminates access charges, as well as equipment management and maintenance from the carrier. Carrier toll charges between the enterprise sites for such calls are also decreased or eliminated. As stated previously, centralized SIP trunking combines the benefits of carrier SIP trunks with any required enterprise SIP trunks, forming an architecture that helps the enterprise maximize its network utilization for voice and UC while minimizing WAN/PSTN costs. The solution includes use of the private WAN for all the enterprise s communications needs across all enterprise sites. The architecture framework is applied to the enterprise such that, during normal operations, there is one or a small number of demarcation points from the enterprise to the PSTN/WAN via carrier SIP trunks at strategic central sites. At the same time, during WAN outages, the centralized SIP trunking architecture provides the necessary support for emergency calls (see the Reliability section). 5

6 What centralized SIP trunking is not Centralized SIP trunking is not simply an architecture that replaces existing distributed PBX or VoIP architectures. In distributed architectures, each branch and each core site has primary PSTN access during normal operations; in addition, the enterprise s call agents are distributed throughout the enterprise. That does not mean that PRIs or trunks are not utilized they may still be a part of the SIP trunking solution, but with significantly reduced roles. The centralized SIP trunking architecture/solution leverages a few core sites containing all access to the PSTN with necessary redundancy and resiliency for the enterprise at the core and branch sites. Centralized SIP trunking can be applied to any enterprise network with considerations. There are three main categories of networks to this approach: PBX environment (which primarily consists of legacy PBXs in the enterprise), mixed environment (which has both legacy PBXs and VoIP-call agents), and VoIP environment. Legacy PBX environment In this category, investment may be necessary to build a VoIP core to carry the VoIP traffic across the enterprise for centralized demarcation to a carrier SIP trunk. Line cards and/or media gateways may also need to be procured for any PBXs that are not yet SIP ready. This investment of building out the core is not a sunk cost. It has two benefits. First, the investment in the core network is for building a foundation for UC and providing a direct upgrade path to VoIP as the PBXs are end of support (EOS)/end of life (EOL). Second, this investment will help drive cost savings by reducing expensive PRIs and T1/E1s at the branches and core and is typically a fraction of the residual annualized savings that centralized SIP trunking offers. Figure 3 shows three types of PBXs (not all protocols are shown for clarity). The top PBX is a very old one that cannot be upgraded with a SIP interface card; it requires a media gateway to perform the translation between the PBX and SBC. The second PBX is upgradable with a SIP interface card. The third PBX is a more recent TDM PBX with SIP support already built in. The carrier network shown illustrates the carrier integration to the PSTN as well as integration to other carrier SIP networks. In this case, the centralized SIP trunk is the demarcation to the carrier network for all off-net calls. Because the carrier network is not the enterprise network, it is therefore an untrusted network; thus, the enterprise requires a session border controller to provide protection, policy, and routing. (Note, in figure 3, S next to the PBX on the left is a VoIP SIP interface card.) Figure 3. Centralized SIP trunking supporting a PBX environment 6

7 Mixed environment This category is similar to the previous category the legacy PBX environment except that some of the enterprise remains on legacy PBXs while a portion has been converted to VoIP. In this case, some investment may be necessary to build a VoIP core or upgrade the existing VoIP core (if one exists) to handle the proposed voice traffic. This investment has the same two benefits as mentioned in the previous section. Shown in figure 4 (not all protocols are shown for clarity) are two PBXs one without the ability to provide a SIP interface card (shown connected to the media gateway) and one that is SIP interface ready plus an enterprise VoIP call agent with a VoIP phone shown (directly connected to the SBC). Figure 4. Centralized SIP trunking supporting a mixed PBX and VoIP environment VoIP environment Figure 5 shows two enterprise call agents (not all protocols are shown for clarity). For on-net calls, an enterprise SIP trunk would be used between the two call agents (not shown in figure 5 but shown in figure 1). For off-net calls, both call agents would leverage the centralized SIP trunk located in the data center or other core location. This solution provides the greatest benefits and savings to the enterprise, as it combines a modern centralized VoIP solution with centralized SIP trunking. Figure 5. Centralized SIP trunking supporting a VoIP environment 7

8 Considerations SIP trunk service provider Not all carriers offer the same SIP trunk service. Some convert SIP to a legacy TDM/SS7 core because they have not yet upgraded their core to an IP core. This type of service provider will have limitations and is thus not desirable. Others have an IP core and offer MPLS throughout their core network. This type of carrier is preferred because the need to translate the RTP (voice) packets and SIP signaling is reduced or eliminated. As with VoIP over the enterprise LAN, QoS capabilities and configurations are paramount on a carrier s SIP trunk solution. Moreover, putting SIP onto the open Internet not only brings security concerns, but also QoS challenges. Therefore, MPLS should be utilized for enterprise SIP trunks (which, recall, are still considered from the SIP standpoint and the enterprise to be on-net). Not all equipment vendors implementations of SIP are the same. Some equipment manufacturers have incorporated SIP extensions or slight differences in SIP RFC interpretations into their products. There may thus be slight differences between VoIP vendors and SIP carriers and SIP carrier interconnects to other carrier SIP networks. It is up to the carrier to validate its network SIP integrations with other networks, in keeping with their operations and caveats. Therefore, it is important to choose a carrier that has performed these validations with the SIP equipment used by the enterprise, and has implemented translations for the other networks with which that equipment interconnects so that the capabilities of SIP are maximized. E911 and emergency services E911 and emergency services in general demand special considerations with carrier SIP trunks because of the historical reliance upon the physical TDM location from which the call is originating. The public safety answering point (PSAP) data is sent about this location, and callback data on legacy networks is based on TDM location. Regarding carrier SIP trunks, this information needs to be associated and sent to the proper PSAP based on different relevant criteria. Also, carrier support for various enterprise locations may vary, so it is important to validate with the carrier that all the enterprise locations will be serviced by a centralized SIP trunk, either locally or remotely, and that the relevant municipality s PSAP can be sent the proper location as well as callback data for that location. Additional technical, regulatory, and legal considerations regarding E911 and emergency services vary by country and region and are beyond the scope of this document. Refer to the Reliability section for discussion of operations under WAN outages. Security MPLS It is possible to use the open Internet for VoIP; however, there are extraordinary security issues as well as quality issues. Therefore, it is highly desirable to utilize a private WAN realized via MPLS. Furthermore, MPLS is an excellent means of helping to deliver QoS for enterprise SIP trunks and VoIP traffic in general. SBC SBCs are special session devices that perform a variety of actions to protect the enterprise from the untrusted network outside of itself. For example, in addition to performing Network Address Translation (NAT) activities on signaling and voice packets, the SBC terminates and originates the signaling sessions (back-to-back user agent), unlike a router, which simply changes the header information and routes the packets. The SBC can also route sessions to the appropriate call agents within the enterprise. All of this makes the SBC a necessary device for carrier SIP trunking, in order to protect the enterprise and help enforce policy. In addition, many carriers require the enterprise to install specific SBCs from specific vendors that run the carrier s configuration for them in order to certify the link from the carrier to the enterprise SBC. This is done primarily for support purposes. Enterprise LAN capacity Enterprises that currently have VoIP solutions in place still need to validate their LAN and private WAN s capacity for the newly-routed traffic requirements that centralized SIP trunking generates. Networks that have mixed VoIP and PBX solutions, along with those that have pure PBX solutions, require LAN and private WAN validation as well to accept the additional voice traffic on the converged network. 8

9 Manageability SIP trunks have rapid configuration abilities with many options not previously available. For example, a seasonal business that has a rapid population change between seasons, such as many in the leisure and entertainment industries theme parks, hotels, resorts, and the like and even universities can deploy SIP trunks instantly as their population growth needs dictate. Then, as utilization declines in the off season, SIP trunks can be released instantly as well. Gone are the days of waiting a month for a PRI to be provisioned by the carrier. In addition, the administrative interface is important, especially if it requires integration with the local enterprise or third-party network management infrastructure. Therefore, the administrative interface must be validated. Careful planning SIP trunks are here to stay, and they can help improve the efficiency of an enterprise s use of resources as well as lower its costs. However, because each service provider has different solutions and each VoIP equipment vendor has different requirements, it makes sense to perform due diligence to help ensure success. This effort should include capacity planning for scoping the correct SBC at the demarcation point, which can perform the necessary call routing and security actions and grow with the needs of the business. LAN and private WAN bandwidth capacities are also essential for success. In addition, LAN, private WAN, and carrier WAN capabilities need to support QoS requirements. Finally, the call agent vendor solution for the enterprise UC and/or VoIP solution should be validated as supported by the carrier. Misconceptions Phone (endpoint) replacement Phones (endpoints) register with the local call agent in the enterprise, assuming a cloud service is not in play. If that call agent is a PBX, the phones register to the PBX; if it is a VoIP call agent, then they register to the VoIP call agent at the enterprise. Centralized SIP trunking does not require phones (endpoints) to be replaced; that would be analogous to thinking you needed to replace phones because the carrier network core used SIP instead of TDM to transport calling traffic. As mentioned earlier, many do not know that their calling traffic (even from a legacy PBX) has been converted to VoIP on some carriers core networks and that certainly did not require endpoint replacement. A centralized SIP trunking architecture promotes a VoIP core in the enterprise that terminates at the call agents. The voice packets terminate at the phones. As long as the carrier SIP trunking service has been validated with the particular enterprise call agent, the phones should not need to be replaced. They only need replacement if the PBX or call agent changes, or if a call agent exists and new features are desired that are not currently supported by the current model of phone. Reliability There are concerns that carrier SIP trunks are not as reliable as the legacy T1 or PRI circuits. However, there are several reasons that carrier SIP trunks are as reliable as or even more reliable than a T1 or PRI connection. To begin, when a T1 or PRI goes down, they are dead and take much time to repair. Even if there are redundant T1 or PRI connections, it could take a trouble ticket call and considerable time to switch over to the backup T1 or PRI or to make manual physical line card changes with the carrier connection compared to a carrier SIP trunk. When a carrier SIP trunk goes down, traffic can be instantly routed to an alternative carrier SIP trunk, and this can be done automatically. When the SIP trunk comes up again, the traffic is automatically routed back to the original carrier. The exception is when, for example, a backhoe operator severs a fiber optic bundle in the street. In that case, a hard physical failure is a hard physical failure, whether it is a PRI or SIP trunk. To help protect against that sort of failure, having carrier diversity and carrier technology diversity is an option. There are many ways to achieve reliability, and much depends on the particular solution makeup and the exact requirements being addressed. For example, one method is to have redundant SBCs at the enterprise edge, interfacing with different carrier services. Carrier A could supply a Digital Subscriber Line (DSL) drop to a site for its SIP trunk. Carrier B could supply a fiber optic drop to the site. (In this particular case, the assumption is that carrier A and carrier B do not share the last mile and can have separate physical drops to the site.) Carrier SIP trunks would have almost instantaneous cutover to the carrier that is still live, even given the backhoe incident. With PRIs and T1s, there is still a fairly long delay in change-over compared to the carrier SIP trunk in such a case. An example of such a redundant architecture is shown in figure 6 (not all protocols or protocol connections are shown for clarity). Additionally, SIP trunk services allow multiple phones in multiple geographic locations to have the same phone number. Thus, even if one phone is not reachable (especially due to hard physical failure such as described earlier), it is still business as usual for all the other phones at the enterprise sites attached to that phone number. 9

10 The same planning that occurs for legacy PBXs or other critical infrastructure must also be followed for SIP trunking. Critical equipment, SBCs, media gateways, site routers, call agents should have the appropriate redundancy as necessary and be backed up by auxiliary power or uninterruptible power supplies (UPSs). From a blocking perspective, this logical constraint should also be managed using the correct capacity planning and the proper call admission control (CAC) and QoS settings. Figure 6. Example of redundant architecture Centralized SIP trunking in different environments (cost savings and possible scenarios) Following are possible scenarios that highlight the potential cost savings associated with deploying a centralized SIP trunking solution. Numerous parameters were used to generate these cases, including an average call hold time of 3 minutes, 4 calls made per day per employee, and a network whose reliability is 99.9 percent (less than nine hours of unplanned downtime per year). These parameters correlate directly to the number of PRIs and trunks provided to minimize downtime which minimizes the ratio of required channels to the number of employees. These parameters represent a conservative starting point to show the SIP trunk savings; many enterprises require more reliability. For networks with percent and percent reliability, the cost savings with centralized SIP trunking are potentially even greater than what is shown here. The values used in the following examples are: intrastate long distance rate used is $0.04 USD/minute, the interstate long distance rate used is $0.02 USD/minute, and the international average long distance rate used is $0.06 USD/minute. Average PRI charge is $300 USD/month (including $100 USD for D-Channel an ISDN signaling/control channel, separate from those channels that carry voice), and trunk costs (local) are $35 USD/month; long distance and toll-free trunks are typically billed by the minute and are not charged a monthly rate. Taxes (10 percent) are also added. Finally, administration costs of PSTN and SIP trunk are included in the analysis. SIP trunks have a wide range of packages and costs. For the cases below, SIP trunks are priced at $20,000 USD/month for access and $25 USD/month per trunk for the calculations. Also, when the trunk is centralized, unused PRI space is aggregated, as is the necessary trunk capacity to support an enterprise. What this means is that to achieve the reliability (not having calls blocked), the waste at each site is reduced significantly, yielding a percent improvement in resource efficiency on the number of sessions required to support the enterprise. Also, with SIP trunks there are no 10

11 D-channel costs, for example, or transfer charges, and long distance is minimized, with the first 1000 minutes per trunk typically provided free of charge. There are three primary centralized SIP trunking transformation starting points in an enterprise: Enterprises with legacy PBXs Enterprises with a mixture of legacy PBXs and new VoIP solutions (call agents) Enterprises with current VoIP solution with no legacy PBXs Enterprises with legacy PBXs In this case, PBXs are used at all the sites. The enterprise uses PRI, T1s, E1s, and DIDs heavily, and all off-site, off-net calls are either local or long distance. These sites already have MPLS service for their data connections, and they have a private WAN as a result. The short-term goal would be to keep the legacy PBXs and implement centralized SIP trunking for immediate cost savings (and the first step to creating a VoIP foundational core for the enterprise). To support this effort, two primary tasks need to be evaluated. The first is to analyze the data network to handle the additional core VoIP traffic that would be placed on it, performing mitigation if need be. The second is to identify if media gateway cards (VoIP cards or SIP cards) can be procured for the PBXs and if not, ascertain what type of media gateways need to be procured to front the PBXs. These costs are highly variable and are not included in any of the scenarios in this white paper. What is included in this case are the cost savings in terms of maintenance, run time, toll reduction, and operations resulting from conversion to centralized SIP trunking. These savings can be used initially to offset the aforementioned costs. In the following table are some variations that distinguish three different enterprise scenarios, providing an idea of the potential cost reductions that result from installing centralized SIP trunking. Note that the scenarios vary greatly between enterprises. Table 1. Indicative cost savings Enterprises with legacy PBXs Comparison Enterprise A Enterprise B Enterprise C Number of phones 8,000 34,000 65,000 Core sites Branch sites PBXs Minutes per month 5.5 million 23.4 million 44.6 million Calculated costs without centralized SIP trunking (annual) Calculated costs with centralized SIP trunking (annual) Cost savings resulting from implementing a centralized SIP trunking solution (annual) $9.68 million USD $42.4 million USD $80.4 million USD $7.73 million USD $33.0 million USD $62.1 million USD $1.95 million USD $9.43 million USD $18.3 million USD The cost savings result primarily from toll reduction, PRI reduction, and T1 and trunk reductions. 11

12 Enterprises with a mixture of legacy PBXs and a new VoIP solution (call agents) In these scenarios, the assumption is that the enterprise has 50 percent legacy PBXs to yield a combination of IP-PBX and legacy PBXs. Because of the starting point of this scenario, the assumption is also that the enterprise is already realizing cost savings by having a partial VoIP solution. However, in these scenarios, the enterprises still rely on off-net demarcation around the edge using PRIs, trunks, and DID lines, even for the VoIP solution. From this starting scenario, the costs for centralized SIP trunking addition are analyzed and provided. Note that the usage, makeup, and dynamics of the three enterprises vary greatly. Table 2. Indicative cost savings Enterprises with a mixture of legacy PBXs and a new VoIP solution Comparison Enterprise A Enterprise B Enterprise C Number of phones 8,000 34,000 65,000 Core sites Branch sites VoIP call agents and PBXs Minutes per month 5.5 million million 44.6 million Calculated costs (annual) $6.33 million USD $27.6 million USD $52.3 million USD Calculated costs with centralized SIP trunking (annual) Cost savings resulting from implementing a centralized SIP trunking solution (annual) $4.38 million USD $18.1 million USD $34.0 million USD $1.95 million USD $9.43 million USD $18.3 million USD Enterprises with only a VoIP solution and no legacy PBXs In this case, the starting assumption is that the current VoIP solution is centralized and optimized to use the enterprise network for all on-net calls, but the demarcation to the carrier network is still present at the peripherals (all sites hop off locally using PRIs, T1s, and E1s). In other words, the benefits of the VoIP solution have been maximized without the use of centralized SIP trunking. As a result, infrastructure bandwidth capacity may need to be increased in certain locations to accommodate the additional off-net traffic that would traverse the enterprise and hop off at a centralized location. Following are results of analysis based on three distinct scenarios. Note that the usage, makeup, and dynamics of the enterprises vary greatly. Table 3. Indicative cost savings Enterprises with only a VoIP solution (no legacy PBXs) Comparison Enterprise A Enterprise B Enterprise C Number of phones 8,000 34,000 65,000 Core sites Branch sites VoIP call agents (centralized) Minutes per month 5.5 million million 44.6 million Calculated costs (annual) $3.76 million USD $16.1 million USD $30.7 million USD Estimated costs with calculated centralized SIP trunking (annual) Cost savings resulting from implementing a centralized SIP trunking solution (annual) $1.76 million USD $6.48 million USD $12.0 million USD $2.00 million USD $9.64 million USD $18.7 million USD 12

13 Enterprises with legacy PBXs that implement a centralized VoIP solution and centralized SIP trunking This scenario involves transforming a legacy PBX enterprise environment to a centralized VoIP solution combined with migrating to centralized SIP trunking. This is provided as a comparison and shows the maximum benefit of a centralized SIP trunking solution with an optimized VoIP solution throughout the enterprise. Table 4. Indicative cost savings Enterprises with legacy PBXs (with combined implementation of centralized VoIP solution and centralized SIP trunking) Comparison Enterprise A Enterprise B Enterprise C Number of phones 8,000 34,000 65,000 Core sites Branch sites VoIP call agents (centralized) Minutes per month 5.5 million million 44.6 million Calculated current costs with legacy PBXs (annual) Calculated costs with centralized SIP trunking and a converged VoIP solution (annual) Cost savings resulting from implementing a centralized SIP trunking solution and a converged VoIP solution (annual) $9.68 million USD $42.4 million USD $80.4 million USD $1.76 million USD $6.48 million USD $12.0 million USD $7.92 million USD $35.9 million USD $68.4 million USD Best practices With centralized SIP trunking, there are some best practices to consider, depending on the particular situation. This is by no means a comprehensive list, but the major aspects are discussed. First and foremost, even if the carrier has an SBC to protect the carrier s network, the enterprise should use SBCs to protect its own network. The SBCs should be able to scale up or down the number of sessions easily for the cyclic needs and/or growth needs of the enterprise. Second, as it is possible to place an enterprise SIP trunk on the open Internet, for obvious security reasons, it is best placed over a private WAN (for example, using an MPLS network). Third, the centralized SIP trunking model promotes the use of the enterprise network for as much of the enterprise communications traffic as possible. Using enterprise SIP trunks as much as possible for on-net calls minimizes the demarcation sites to those that are strategic and redundant. Also, the network must be able to carry the enterprise SIP traffic, which includes the private WAN (MPLS). Next, because the enterprise is relying on a few core network demarcation points, the edge components and primary network components should be redundant and backed up with UPSs. Also, if the enterprise has mission-critical requirements, carrier diversity should be considered. Next, when considering SIP trunking carriers, understand if or not the carrier controls the SIP network all the way to the PSTN integration. Understand, as well, exactly what geographic regions the carrier s control of its service covers, vs. partner networks and third-party networks. Understand the limitations, if any, of support of SIP and advanced SIP features from the carrier. Lastly, when setting up the SBC, it is a good idea to match the CAC settings to the session capacity provisioned. HP Centralized SIP Trunking Service HP Centralized SIP Trunking Service is one of the HP UC Services, which can help you build a foundation for transforming your business communications. The solution gives you the option to incrementally add features with a right-sized approach at a pace appropriate for your budget and business requirements. 13

14 HP offers services that can help your enterprise reap the immediate and downstream benefits that SIP enables. HP UC Centralized SIP Trunking and PRI Reduction Service mark the beginning of VoIP enablement. It also implements an enterprise voice backhaul solution to a centralized demarcation location to the WAN carrier. Designed for legacy networks or newer VoIP networks, our centralized SIP trunking solution offers significant benefits: accelerated business communications, improved information transfer and file sharing, enhanced worker productivity through conferencing and collaboration capabilities, and reduced mobile phone costs. Conclusion As SIP trunking becomes more common and adopted by enterprises, it is important that the right UC foundation be built for the enterprise, and centralized SIP trunking is part of that foundation. Centralized SIP trunking yields the largest cost savings and benefits for most organizations because of the efficiencies it produces as well as the toll charges and the administrative costs it reduces. Centralized SIP trunking is also a method of architecting for the cloud. This document has covered aspects of centralized SIP trunking, including its considerations, misconceptions, and benefits, and has provided case studies to illustrate the potential cost savings. Centralized SIP trunking can offer cost savings in many cases immediate cost savings even to enterprises serviced completely by legacy PBXs. It can also be applied to mixed and full VoIP deployments. Note that because each enterprise is different, the actual cost savings may not match, may be lower, or may even exceed those shown in this document. HP can provide a cost savings estimate based on client-supplied parameters. For more details, please contact your HP services sales representative. Glossary of terms BRI (Basic rate interface) CAC (Call admission control) DID (Direct inward dial) DSL (Digital subscriber line) EOL (End of life) EOS (End of support) IETF (Internet Engineering Task Force) IM (Instant messaging) IP (Internet protocol) ISDN (Integrated services digital network) LAN (Local area network) MGW (Media gateway) MPLS (Multi-protocol label switching) PBXs (Private branch exchanges) PRI (Primary rate interface) PSAP (Public safety answering point) PSTN (Public switched telephone network) QoS (Quality of Service) RFC (Request for comments) RTP (Real-time transport protocol) SBC (Session border controller) SIP (Session Initiation Protocol) TDM (Time division multiplexing) UC (Unified Communications) VoIP (Voice over Internet Protocol) WAN (Wide area network) 14

15 For more information To know more about how you can improve the business benefits of a SIP trunking deployment and build a solid UC architecture, visit: hp.com/go/uc. Get connected hp.com/go/getconnected Current HP driver, support, and security alerts delivered directly to your desktop Copyright Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. 4AA3-8768ENW, Created December 2011; Updated November 2012, Rev. 1 15