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

Advertisements