Remember reading all of those headlines? “ISDN is finished,” wrote Information Age in 2015 based on BT’s announcement that the company believes 2025 will see BT ISDN migration to SIP (or rather IP) completed.
With the SIP market estimated at £120 billion by 2020, it is evident the transformation is heading toward completion. Question is, what do you need to consider?
Download our checklist here. We’ve created a simple but effective ‘at a glance’ guide to migration and the required considerations.
With our recent article on BT Cloud Phone in mind, many readers have been asking questions surrounding what to consider when moving ISDN circuits over to the world of IP, specifically SIP.
No matter what you’ll be told via the marketing of SIP providers, ISDN remains a very predictable solution for telephony. With nailed up circuits that are not subject to the variability of Internet performance, businesses typically deploy ISDN and forget about their installation due to high uptime and quality. An example? While working from an office with very poor Broadband speeds this week, I went to make a call from my cloud phone. The results? Not good. However, as we continue to discuss, poor performance is becoming less of an issue.
With the above said, we know ISDN is effectively a product which is in decline and your business will no doubt be forced, at some stage, to migrate your ISDN services to SIP (or similar technology). Other than being ‘forced’ there are significant benefits to SIP vs. ISDN in respect of flexibility, product features and ease of adding further channels, ie scalability. In the is article, we’ll discuss migrating to SIP in general with some key topic areas to assist IT Managers through the buying process. At a high level, customers are connecting to SIP over two types of connectivity technology:
- Private WAN connectivity - MPLS and VPLS
- Internet connectivity - Single and multi-provider
The above will be discussed from the perspective of UK and Global organisations looking to deploy SIP services, i.e. moving away from traditional telephony.
Your concurrent calls vs CODEC
The amount of calls your business currently utilises will be based on either ISDN-2 or ISDN-30 or multiples of each circuit type. In this respect, your ISDN channels will directly correspond to SIP. The two typical CODEC’s used (CODEC is a type of compression used to compress voice data) is typically based on G729 or G711. In today's world of good broadband speeds and 100Mbps / 1Gbps Ethernet leased lines, G711 is used in the majority of cases for improved quality reasons. We recommend an allowance of 100k per call concerning bandwidth. On some Broadband circuits, 100k per call may have the potential to congest the upstream bandwidth especially if the circuit is shared between telephony and other applications such as email and Internet browsing. Where possible, we always recommend installing a separate stand-alone Broadband circuit. If your business is a medium to large Enterprise, you’ll be looking at private MPLS / VPLS connectivity or an Ethernet leased line. In either case, ensuring enough bandwidth exists vs. concurrent calls is of utmost importance. The maths is relatively easy: 30 concurrent calls equals 300k.
"The maths is relatively easy: 30 concurrent calls equals 300k."
Latency, Jitter and SIP performance
With bandwidth covered, you may be forgiven for thinking your business is all set. However, bandwidth is only part of the story as the performance of jitter and latency must be considered. Latency and jitter are performance factors which dictate how we your voice call performs across a network. In short, latency is the overall round trip of data, jitter is the space between each packet (block) of data as the call traverses a network. In general, most IP networks today are good enough for a general level of service. The expectations will vary depending on where and how the user is accessing the cloud-based service. Remember, though; ISDN is a fixed office service so some of the negativity surrounding performance issues outside of the office is not a comparable feature to ISDN. Migration from ISDN to a SIP service will result in your users falling into three different catagories as follows:
- User type A: Always in the offices and will, therefore, receive a predictable level. << Essentially comparable to ISDN.
- User type B: Sometimes in the office but occasionally works from home. << ISDN with a little flexibility.
- User type C: Always out of the office using various methods of connectivity. << Most unlike ISDN!
The more challenging user type is clearly user C due to the unpredictability of the kind of connectivity used. With this said, the Cloud Phone SIP application will usually run on your mobile, and where connectivity is simply not suitable, the user may revert to using standard mobile calling. The overall issue of predictable bandwidth remains a problem today due to the number of factors such a low cost, poor performing wireless connectivity within a cafe (as an example). I’m taking a positive stance since 4G connectivity is becoming more prevalent.
Your access technology and type
When considering migration from ISDN, the IP connectivity utilised will fall under two categories with multiple connectivity types under each service. We refer to these groups as public or private based IP networks. The average Enterprise business will usually connect their branch offices via a private WAN service such as MPLS (Layer 3) or VPLS (Layer 2).
The actual connection type and considerations are listed below:
- Broadband - ADSL2 and FTTC (Fibre to the Cabinet)
- EFM - Ethernet First Mile
- Ethernet Leased Line - 100Mbps and 1Gbps
MPLS (Multi Protocol Label Switching) VPRn (Virtual Private Routed Network)
A private MPLS network offers predictability across UK and Global connectivity via the use of service provider traffic engineering and QoS (Quality of Service). This capability roughly translates into an SLA which offers voice and video quality by covering both latency and jitter of packets as they traverse the WAN. MPLS is a private based technology which does not require the overhead or complexity of encryption and security services such as IPSec. The main issue for private based connectivity is where the service breaks out your connectivity to SIP; this could either be within the provider's cloud, or an interconnect at a particular location.
* VPLS is also a technology where SIP may be used.
Internet - Public IP
The difference between using the term ‘Internet’ or ‘Public IP’ is important to discuss. Organisations looking for predictability will always try to use a single IP backbone, i.e. a single Internet provider. The benefits are clear since traffic (voice packets) will traverse a single network meaning latency remains predictable on an end to end basis. With this said, is it realistic in today's world to expect traffic to stay on a single network with users so remote? Think to work from home, the local cafe, your customer's office, service station and so on. The good news is that technology is getting better with applications detecting available bandwidth and latency. If conditions are less than ideal, the application will reduce CODEC quality to make use of available bandwidth. What's more, ISDN does not offer such services and functionality off site once disconnected from the office. In this sense, while the performance of SIP over connectivity outside of the campus might sometimes be less than satisfactory, the option vs. ISDN is a major flexible benefit. 3G and 4G services (as mentioned earlier) are becoming much more prevalent meaning that external users are receiving a much more stable and bandwidth rich service.
The use of a single provider backbone vs. multi providers or access via multiple locations.
The subject of security is clearly a consideration and thoughts must be made as to how secure your network architecture is based on where your SIP elements exist. Outsourcing SIP comms to a provider should ensure your security is taken into account since architecture will be part of their presales service (or should be). Again, depending on the scale of your business and overall access points and so forth will dictate how complex an issue security becomes. There are many aspects such as wifi access (as an example). We have listed a few links below.
VoIP Security Vulnerabilities - Security Vulnerabilities that have been publicly disclosed in VoIP products
VoIP Security Forum - Forum dedicated to VoIP security issues
Note: The above links are Cisco resources.
SLA (Service Level Agreement)
The SLA requires careful consideration, especially for Global companies. When designing architecture for international connectivity, the SLA doesn't provide complete clarity. This is largely because unless locations are metropolitan, the tail circuits (the circuit used to connect your office to the provider) might extend over long distances. This, in turn, has in impact on latency which will not (for the most part) be defined with the SLA document. With ISDN services, the architecture is simple with local breakout within each location. However, with SIP or VoIP implementations we need to consider where the voice traffic will break out of the network, especially a consideration when running an Internet VPN or MPLS / VPLS private architecture. We view any SLA as a commercial agreement and your design should not be based on the contents of an SLA document. The SLA should provide confidence within specific areas such as packet performance and uptime but only to a basic level.
Resiliency and Diversity
We mentioned within the introduction that ISDN services are predictable and receive a high level of uptime. To maximise the uptime of your SIP services, providers can present highly diverse dual circuits at head office locations. The type of diversity is dependent on site survey and budget which will increase depending on whether or not the solution will include architecture such as dual Ethernet or a lower cost option of EFM or Broadband circuits. Where lower cost options are a consideration, attention must be paid to aspects such as upstream bandwidth where there is a potential of congestion creating poor performance. EFM is a symmetrical service and thus is more predictable in a failover scenario. There is often an option to decrease the CODEC quality on the failover circuit meaning more calls will fit into a circuit where bandwidth is contended.
Fig 2. Diversity.
There are some major benefits
SIP services are incredibly flexible and feature rich with options way in advance of ISDN capability. As an example, adding further channels is incredibly easy and cost effective, and each user can customise their service to suit their particular needs from line divert to voicemail and even custom IVR features. Above everything else, your SIP service is now with you via phones, tablets, laptops or dedicated desktop PCs with the very same feature set.
Conducting a SIP Pilot
Depending on how large your business is, conducting a user pilot of SIP is always a good idea. For example, consider converting one of your smaller branch offices to SIP and producing a test plan. Any issues or problems are then well positioned to be ironed out before full roll-out across the business.
With all of the above said, careful consideration must be given to the migration of corporate services when comparing your existing ISDN to SIP. This amount of thought is directly comparable to the complexity, scale and required features of your business. SIP interoperability is always a consideration if your organisation is combining a self-managed services (e.g. Cisco Call Manager, Avaya, etc.) with a service provider SIP gateway. There will be a feature set associated with your gateway which may / may not be compatible with your service provider of choice. The gateway style of SIP service is one which BT in not pursuing with intent. BT look for being moving forward with dedicated cloud-based services such as BT Cloud Phone which we have recently reviewed. We appreciate they will be businesses already invested in the gateway model will require simple SIP trunking services which are readily available.
If you would like to discuss how BT are well positioned to move you away from ISDN, simply get in touch using the contact us form or the buttons on this page.
Further Links: (Very technical!)
RFC 3329 Security Mechanism Agreement for the Session Initiation Protocol (SIP)
RFC Draft SIP digest authentication relay attack