Tagged: SIP

SIP Trunk Provider Evaluation 2019 by the Eastern Management Group

In this post I like to highlight a SIP Trunk Provider Evaluation by the Eastern Management Group. I came across a nice article regarding the evaluation of (some) SIP Trunk Providers which was carried out by the Eastern Management Group.

In this study 29 SIP Trunk Providers were evaluated based on a survey. More than 3.000 IT managers were asked. As far as I could read the focus resides primarily on SIP Trunk Providers in the US and such with global reach.

Source: https://pixabay.com/de/vectors/statistik-umfrage-webseite-vorlage-1606951/

Conclusion, opinion and summary

In case your are about to plan your migration from ISDN to ALL-IP/SIP Trunks or you are considering to consolidate your SIP Trunk connectivity this study might provide you some insights and metrics to get to a decision on which SIP Trunk (Provider) to choose.

However, 29 SIP Trunk Providers are just a few. Depending on where you need a SIP Trunk you might need to research which are available at a certain world region, country and local area. As always on the market there are small and large SIP Trunk providers offering a different feature set for the SIP Trunk Services.

I recommend to take a closer look to what’s offered in detail and what SIP Trunk “architectures” are serviced, e.g. dedicated (physical) link vs. logical link (via existing Internet/MPLS connectivity), encrypted traffic support, clip no screening support, SBC support/compatibility (are there recommended SBCs/IP-PBX by the respective provider?), call authentication/authorization requirements…

Additional resources

Design options for PSTN SIP Trunk links

In this post I show and explain two SIP trunk (topology) designs. This will give you a first glimpse on what you could do if you plan to migrate from ISDN to SIP (ALL-IP) or if you think about consolidating or distributing your PSTN access links, either to reduce costs or increase availability.

This post is just a high level and simplified overview and under no circumstances a complete design or something you can directly apply for your company without knowing your requirements, needs and related dependencies. I don’t go into detail regarding Microsoft Phone System/PBX/SBC deployments and connectivity.

Option 1: Central PSTN SIP Trunk links

Central PSTN SIP Trunk links with two options (example)

Central PSTN SIP Trunk links are one or more sip trunks terminating centrally on a session border controller (SBC, redundant or not redundant). The above figure displays two options:

Option 1: Connect to PSTN via Internet

  • no QoS
  • “no SLA”
  • call and media quality might vary depending on your internet link (bandwidth, latency, roundtrip latency (RTT), jitter, packet loss …)
  • commonly low priced

Option 2: Connect to PSTN via “MPLS” or “MPLS Light”

  • QoS
  • SLA
  • PSTN service provider delivers a dedicated connection link, either via existing MPLS (if PSTN and MPLS/WAN provider are the same) or new IP-link “MPLS Light” (dedicated IP-link and connection only for voice SIP Trunking).
  • commonly costly

Option 2: Decentral / distributed PSTN SIP Trunk links


Decentral / distributed PSTN SIP Trunk links (example)

Decentral PSTN SIP Trunk links are one or more sip trunks terminating on a session border controller (SBC, redundant or not redundant) at each location/site. As the above drawing shows each site has its own PSTN link. In my experience many companies have this architecture if …

  • they are still on ISDN,
  • or have several and different PBXs per site
  • or have local PSTN service provider and did not develop a PSTN provider concept for a central approach
  • or don’t have a highly available WAN in place for a central approach (e.g. no redundant MPLS links, no SD-WAN, …)

Conclusion, opinion and summary

Now, as you can see, there are two major options for designing PSTN access with IP-based SIP Trunks. However, a combination of both is possible, too.

In large and multinational deployments (>10.000 users) you might find a mix of above options within world regions, for instance, central PSTN sip trunks per world region (NOAM, LATAM, North Europe, South Europe, MEA, APAC West, APAC East, APAC South, APAC North). One in a while you might come across certain constraints at a site which make you temporarily stick with ISDN. B

Finally, it all comes down to your requirements, needs and goals. Due to the shift of how we work, how we can communicate and collaborate today, I would prefer and go for a “slim” PSTN access concept.

Additional Resources

What to keep in mind before migrating to ALL-IP?

In Germany, PSTN carriers announced long time ago (!) to decommission their legacy PSTN access links (analog/ISDN …). Today, mid 2018, we are still not yet on ALL-IP everywhere. Migrations towards ALL-IP (SIP) are still in progress.

The unified communication projects I carried out the last years almost always included advisory services to design and deliver a future proof ALL-IP concept for different voice (PBX) infrastructures (Alcatel-Lucent Enterprise OmniPCX, Cisco Unified Communications Manager, Skype for Business (onprem/online), Teams …). It’s daily business to think and plan for ALL-IP. Designing and planning solution and services for communication always includes at least the discussion of PSTN trunk design options to a certain level depending on the consulting engagement and scope of work. Usually in large and international enterprises (>10.000 users) ALL-IP migration can be a complex and long-term project endeavour. In this blog post, I’d like to (quickly) point out on what to pay attention, too, besides the default information worker office telephony service enabling users to make/receive PSTN calls, forward calls to a PSTN phone number or enable simring between a soft client (e.g. SFB/Teams) and mobile phone…

Let’s dig in a bit deeper into large-scale ALL-IP (and VoIP) projects: Typically, international companies have almost everything you can (and might cannot yet) imagine in their PBX infrastructure. Therefore it’s essential to define targets and work packages as below first …

  • Source Architecture Analysis (as-is analysis)
    • … to discover
      • all assets …
      • all capability …
      • all configurations …
      • … linked to any of your PBXs, e.g. analog phones, digital phones, IP phones, DECT phones, …
    • … analyze
      • PBX configurations …
      • … to check for any special devices connecting to PSTN, e.g. modems, alarm server, intrusion detection system, card terminals …
  • Target Architecture Development
    • Digital workplace vision and strategy
      • …
      • ALL-IP
      • …
    • Digital workplace architecture
      • …
      • Telephony Services (ALL-IP as a part of the digital workplace)
        • PBX (global PBX infrastructure)
        • PSTN (global PSTN access)
      • …
  • (Telephony Services) Migration Architecture Development
    • …
    • migration strategy and plan development
      • Global ALL-IP strategy and plan
      • migration strategy and plan for non-ALL-IP-compliant devices
    • …
  • Service Operations Architecture
    • …
    • utilize a document or configuration management system to store all gathered contracts/details/configurations/… (operative process because it might change over time …)
    • …

For large infrastructure it helps to split up the project at least into two (parallel) work streams or sub-projects (if possible), for instance:

  • Global PSTN access
    • ~”external voice connectivity”
    • This sub-project has to focus on PSTN connecivity on a global scale.
    • Global PSTN carrier / provider management
    • Global PSTN provider / PSTN SIP Trunk Architecture Concept
    • Comply with national telecommunication regulations and laws
    • Simplify global PSTN access infrastructure
      • Define a clear PSTN access / feature list
      • Consolidation of PSTN access
      • Centralization of PSTN SIP trunks (if possible)
      • High Availability
    • Simplify global PBX infrastructure connectivity
    • Consider different PSTN sourcing options
  • Global PBX infrastructure
    • ~”internal voice connectivity”
    • This sub-project has to focus on PBX infrastructure on a global scale, too.
    • Assess site / work space requirements
    • Assess user (group) requirements
    • Define and establish standards per site and user profile/s
      • Example user groups: office worker, production worker, indoor mobile worker, outdoor mobile worker …
      • Example site / work space (profiles): production plant, logistics, warehouse, sales office, R&D, administration, …
    • Migrate all non-IP endpoints to IP (based on the previous discovery)
    • Simplify global PBX infrastructure
      • Single PBX vendor or service
      • Reduce legacy endpoints if applicable
      • Consolidate PBX
      • Centralize PBX
      • High Availability
    • Simplify global PSTN access connectivity
    • Consider different PBX sourcing options

The above description is a high-level summary on typical things to keep in mind for telephony services as part of a digital workplace architecture. I hope it might guide you a little towards some telephony and ALL-IP hot spots to be aware of. Furthermore you can find more to read regarding to ALL-IP and special voice services below…

Further resources