Considering a new SIP installation or migration? What could go wrong? Invite Techtarget.com writer Robert Sturt to your office, free. SIP procurement step-by-step.
Your specific requirements - user quantity vs CODEC and voice / SIP features to establish bandwidth
Pricing from Gamma and BT Business
Connectivity type including using the Internet and how to interconnect MPLS (Multi Protocol Label Switching) or VPLS
Ensuring latency and jitter are within operating parameters
Aligning bandwidth vs CODEC type and connectivity method - e.g. Ethernet or Broadband
It’s fascinating to learn the opinions of a connectivity procurement expert vs the considerations required when migrating to the feature rich world of SIP trunking. Recently, I discussed a past SIP trunking implementation with a client - their Enterprise discovered the significant new investment into UC (Unified Communications) was not quite as expected. A few years back, the discussion surrounded VoIP but today, we are in a world of end to end sharing from basic files through to complete collaboration, desktop sharing and video.
The IT team were commended by their peers for removing a legacy traditional ISDN infrastructure into the world of IP. At a base level, the change made sense because a whole world of presence, collaboration, video and so forth was opening up to their users and extranet partners. All in all, an added competitive edge to the business and increase to user productivity. So what could and did go wrong? Plenty as it turns out.
The WAN vs SIP design
The underlying WAN provider had not been aligned with the SIP requirements across nearly all aspects. The HQ was perhaps the best prepared with plentiful bandwidth provided by 1Gbps resilient and diverse circuits. However, smaller brand sites were operating with less bandwidth and no control or governance of the traffic. With daily bandwidth spikes creating congestion, all forms of traffic relating to collaboration, video and voice were dropping. Revisiting the connectivity drawing board was most definitely required.
As with cloud based technologies, the performance of applications are governed by the underlying infrastructure. Let’s look at the options together with the key areas for consideration.
MPLS - (Multi Protocol Label Switching) and VPLS (Virtual Private LAN Service)
Viewed by some as the only option for interconnecting your business with the SIP providers services, MPLS (and VPLS) offer privacy, traffic separation, QoS (Quality of Service) and aggressive performance SLA’s (Service Level Guarantees) across latency and jitter.
Although many companies would not view encrypting voice traffic across the public Internet as necessary, MPLS means you do not have to make this consideration with SIP trunks. All traffic is sent up to the SIP providers network via a private infrastructure. MPLS also allows organisations to maintain VLAN separation (recommended) to further add security. QoS is the most talked about feature of private WAN services because of the inherent ability to prioritise your voice traffic. As we discuss within the workshop, QoS must be aligned with the required bandwidth which is dictated by the CODEC type and bandwidth requirements (see further reading).
Fig 1 demonstrates the features of an MPLS VPN in more detail. Here, the call CODEC type has been defined as G711 which requires approximately 87k per voice call. If the Enterprise business in question requires 10 concurrent calls, the output would equal 870k of bandwidth. Other alternative CODECs include G729 used in many SIP trunks implementation.
If the traffic is entered into the EF (Expedited Forwarding) traffic prioritisation setting, the user will receive a predictable level of service because the traffic will be strictly prioritised on an end to end basis.
Are there any disadvantages of connecting MPLS providers into MPLS
The first is fairly obvious. You require an MPLS network. If your business is currently operating over a hybrid WAN or an Internet VPN, there will be additional cost over and above your SIP trunk pricing budget. Let’s assume you business has previously invested into MPLS. The question in this scenario will revolve around how to interconnect your MPLS network with the SIP trunk providers service. Typically, most major SIP providers (Gamma, BT and so forth) operate out of data centres which are also occupied by major service providers. If this is the case, a back to back or patch cabling service will be needed to connect your MPLS port into the SIP service. With this said, your organisation may not be utilising data centre space which means an on-net MPLS port will be needed which, as you may have guessed, will impact cost further. Over and above SIP pricing, there is also the design to consider. We’ve made the interconnect process appear relatively straightforward but due diligence should be performed to ensure there are no single points of failure. This may require failover provisioning depending on uptime requirements.
Connecting SIP providers into public IP
We recently wrote an article where we made a clear delineation between Internet and public IP. In my mind, business grade SIP services between offices should be sent over the same ISP backbone to avoid unpredictable levels of service. Organisations which are using Global Internet providers of multiple UK providers are ultimately taking a risk. Of course, remote users are the exception here because their SIP session may well begin out of a hotel from any location across the globe. UC Applications are becoming more feature rich and, as a result, can sense the connectivity status and restrict service if latency is too high or bandwidth too low. We refer to using multiple providers as ‘connecting over the Internet’ and a single provider as ‘public IP’.
Fig 2 shows the differences between the Internet and public IP.
Using a public IP backbone is perhaps the most straightforward method of provisioning SIP. A business grade leased line such as BTNet (BT’s premium product) will offer predictable bandwidth and good latency performance. The negatives are the aspects we have discussed earlier which surround a lack of traffic control and privacy. In the main, Ethernet bandwidth is prevalent which means congestion is becoming less of a risk. BT even SLA their service performance when clients combine the BTNet leased line with their SIP products. A leased line will clearly add to the overall SIP trunk pricing.
Hosted vs On premise
Whether your organisation would benefit from hosted or on-premise depends on your strategy and wether or not applications and services are cloud based or located within your HQ site. There are many Enterprise organisations building private cloud services meaning that the SIP / voice solution will become another aspect of the infrastructure. There are numerous benefits with a hosted infrastructure including feature set and capability updates as part of your service and outsourced expertise. On the flip side, there is a loss of control with not hosting the equipment onsite at your office. Change requests are clearly (for the most part) much quicker when implementing on-premise services.
Not all offices will be connected to high bandwidth Ethernet services. We recently wrote an article on MPLS over ADSL which highlighted some of the issues with ADSL broadband services. In short, uptime and lack of resilience is perhaps the most notable issues. With this said, smaller offices will be just fine when using ADSL as uptime is not so critical. The upstream bandwidth should be carefuly considered vs concurrent calls together with other traffic operating over the circuit.
SIP Resilience and Diversity
Resiliency and diversity have been written about extensively on our site. Whichever service provider you use, the products will be available to engineer no single points of failure, subject to survey. The example I mentioned earlier within the article is notable as their head office was using two different tail circuit providers. In this scenario, the solution was not diverse since neither local loop carrier would be able to comment on where routes of commonality existed throughout the wholesale network. ADSL, EFM (Ethernet First Mile), GEA and so forth are not particularly configurable as diverse circuits. Over and above connectivity, todays SIP trunks are protected by hardware resilience and clustered automatic failover equipment.
Global SIP providers vs UK implementation
As with all aspects of connectivity procurement, Global Enterprise organisations must consider SIP carefully. In this main, this is because crossing the Pacific of Atlantic oceans (there are other expanses of water) are a little time consuming for IP traffic regardless of QoS and well engineered backbones. The WAN providers SLA is often a little misleading because the latency and jitter performance will cover the core network and does not include the tail circuit. As an example, international connectivity may well include an SLA (for example) of 180ms across two global locations. With tail circuit latency added on, the latency increases to (for example) 260ms. On paper, Global WAN SLA’s look to be within parameters of SIP performance but, in reality, the real world performance may be detrimental to SIP performance quality.
The idea of our SIP trunk pricing and providers workshop is to help prospective users of SIP to align their specific business with capability. We’ve implemented many of the ideas you read about here (and discuss within the workshop) into our own presales workflows. We continuously look to improve the workshop content with our business gaining more clients and our clients gaining more success when implementing SIP.
Over time, we will be writing about aspects such as number portability, soft client vs on premise phone systems and support services.
SIP (Session Initiation Protocol) is the leading method of leveraging todays feature rich Unified Communications including presence, collaboration, voice, video, desktop sharing and so on.
ISDN is a known quantity both in terms of expected performance and the requirements to install for any given business. The world of SIP is somewhat different.