Webex Contact Center PSTN Decision Tree

Webex Contact Center requires PSTN (Public Switched Telephone Network) access so you can do stuff like get phone calls from callers and to agents. Webex also requires stuff like Entry Point Mappings to be in an e.164 format so even without PSTN you still need the numbers, but I couldn’t think of a reason a cloud contact center would be able to access the PSTN…

There are lots of options when it comes to connecting PSTN. This is great from the perspective of design and flexibility, but all the options can be daunting and some have drawbacks others don’t so it’s important to talk through what your requirements are heading into it because you can only have one method of PSTN integration. This decision tree has the question I most look for when choosing the right PSTN option for customers. This article does great at showing some of the basics around each option as well – Set Up Voice Channel for Webex Contact Center.

PSTN Access Methods

There are 3 methods of PSTN access, but actually 4, or 8. But who’s counting, It’s simple.

VPOP Bridge

VPOP, or Voice Point of Presence, is the term used when connecting your PBX or SBC directly to the Webex CC media nodes. This was the first method introduced by Cisco where the customer would use a CUBE or SBC to direct calls to and from their Webex CC tenant via SIP. In this setup the customer is responsible for integration to their own PSTN telco provider or CUCM/PBX in order to route calls.  All calls to and from Webex CC will traverse these SBCs.  VPOP is currently the only method (as of 12/2022) that supports the new RTMS media bridge which provides some cool functions like regional ingress/egress points for calls.  This RTMS platform is being expanded to the other PSTN options currently.

There are 4 different transport options for a VPOP configuration, but at the core, it is based on the same SIP setup.

  • At its simplest UDP SIP traffic over the internet or “over the top”. This is plain unencrypted SIP traffic. While it’s simple to set up when used over the open internet it does have the possibility of calls being exposed to the internet. That said I do want to provide some caution and let you know a lot of very large providers use this method to provide PSTN service and chances are your call is on the internet unencrypted anyway at some point.
  • SIP TLS is the same “over the top” transport, but it provides TLS encryption for both the SIP packets and audio packets. This encryption is certificate-based so you will need a security license if using CUBE and you will need to manage the certificate trust store.  An expired cert means calls stop.
  • L2VPN is an option if you either want a little extra security, TLS isn’t an option or you have security restrictions of accessing resources over the internet.
  • Webex Edge Connect is the Cadillac version of connectivity. With this method, you would connect through Webex via a private Equinix MPLS link. The MPLS transport provides an encryption layer, but can also provide guaranteed bandwidth and QoS (quality of service) over the link.  Webex Edge works for all Webex traffic too, so it can provide the same security and guarantees to your meetings, messages, and calling as well.

Webex Calling

Webex Calling integration can make a lot of sense if you have or are planning to have Webex Calling in your organization and we can often share the same PSTN provider as the Webex Calling service is using. One thing to point out is that if your agents are on Webex Calling no matter what PSTN option you use, you can always use a Webex Calling extension as the agent extension is in Webex CC and when you do this you gain some of the quality of a single leg between the platforms as opposed to multiple PSTN hops to an agent.

If you choose this option, Webex CC will use whatever PSTN method is configured in Webex Calling to reach the PSTN and you can create Entry Point Mappings from any of the numbers seen in the Telephone Numbers portal. In Webex Calling we have three different PSTN options, but it’s important to note that only two of them are supported with Webex Contact Center.

  • Local Gateway (LGW) is similar to VPOP, but the call terminates to the Webex Calling platform instead of direct to Webex Contact Center.  The configuration of the CUBE gateways is slightly different and only Cisco CUBEs are supported.  The configuration also uses a registered SIP trunk instead of IP authentication like VPOP.  The connection is always TLS secured as well.  You can still use this option if you have Webex Edge Connect deployed for added quality.  The main limitation of this method is that each registered trunk is only capable of supporting 250 concurrent calls. If your agents are using PSTN agent numbers instead of Webex Calling extensions this effectively doubles the concurrent call count as well. These sessions are shared with the Webex Calling subscription too so you will need to account for that shared capacity.  To note Webex Calling does support multiple gateways per location and there are workarounds available to support multiple registrations on a single gateway, but in my opinion, they are not pretty and it’s probably better to avoid them if possible. In the right deployment, this can still be a very effective method that provides some simplicity to your design, but if you are expecting concurrent contact center traffic over 100 active calls then you might look elsewhere.
  • Local Gateway has a newer option for delivering calls based on DNS. This is referred to in the documents as “Certificate-based Trunk”. With certificates in place to verify the CUBE endpoints and provide encryption, you can fore-go the registration and scale past the 250 concurrent call limit. Inbound calls from Webex will locate your CUBE based on DNS records and then use the CUBE’s certificate will provide necessary protections. This method requires the gateway be reachable from the internet and (behind NAT is not supported). You will also need to install and maintain a certificate from one of Webex’s trusted certificate authorities. Because of the recent changes to certificate validation periods etc, this certificate will need to be renewed yearly, just like you would with Expressway. If that certificate expires, so does the Webex trunk so this method does provide some measured risk if you aren’t the type to stay on top if certificate renewals.
  • Cloud Connected PSTN Providers (CCPP) have been available from the start of Webex Calling and even back to the Spark Calling days. When using a CCPP you maintain a relationship with your telco, but select telcos have direct peering points into Webex calling so that a local gateway is not required. Many of the telcos also support number provisioning and porting directly from control hub. In many cases, these telcos will have a special pricing contact center or agents due to the fact that your typical agent has a different PSTN usage pattern than a typical office worker and most of these use a per-user model for pricing.
  • Cisco Calling Plan is not supported by Webex Contact Center. This is important to note and is confusing because technically it does work, however, due to the same per-user pricing models that a lot of CCPPs use, this service is not intended for use with Webex Contact Center and is technically a violation of the Terms of Service.

Webex Contact Center PSTN

The last option is Webex Contact Center PSTN.  Similar to Cisco Calling Plan for Webex Calling, the Webex Contact Center PSTN plan is a Cisco-provided PSTN option where Cisco maintains the PSTN connection in the Webex Cloud and bills you, the customer, directly. This plan is priced per agent and can take into account the inbound caller leg, the agent leg via PSTN, and supports Toll-Free numbers.  This is a great option for full cloud deployments or deployments that are PBX agnostic.

Agent Delivery

Now that we’ve discussed number delivery to Webex CC, now we get to talk about getting calls to your agent. The good news is whatever choice you made earlier will likely work with the agent delivery side as well.

VPOP Bridge

If you went with VPOP bridge for your setup Webex CC will simply send outbound calls to the gateway. This works for routing extensions as well as DIDs so however your agent puts their phone number in, it’s your responsibility to make sure that the number routes.

Webex Calling Integrated

Webex CC integrates with Webex Calling for the agent delivery by default and if you specify an extension instead of a PSTN agent number, the call will route to Webex Calling. This is really simple if your agents have extensions on Webex Calling, but once there the call will also take any number routes you’ve created so you can egress Webex Calling via a local gateway to hit your UCM, PBX or whatever telephony system you’re using.

If you are using a CCPP or Premise-based Gateway for as your Webex Calling telco, and the agent provides a PSTN number as their agent number, then Webex Calling will use that PSTN connection to route the agent leg of the call as well.

Webex Contact Center PSTN

If you are using Webex Contact Center PSTN then you have more options. Webex Contact Center PSTN is priced based on the ingress call as well as the agent leg, however Webex CC is still Webex Calling integrated so if you’re agents are using an extension the call will route to Webex Calling like in the previous setup. If the agent uses a PSTN number the call will route out the Webex CC PSTN.

Options, Options, Options

In closing, there are lots of options when it comes to connecting your customers to Webex Contact Center.  I said three, but it’s really a lot more so it’s easy to get confused with caveats so leverage your Cisco account team and partner to help with selecting the right path.