Can Webex Calling accommodate Multiple PSTN?

[jo13]

Hello everyone, my engineering team is doing a Proof of Concept for Webex Calling in one of our customer. Customer is currently using CUCM for on-prem solution, but is interested in switching to Webex Cloud Solution for their Collaboration. In the customer's existing condition, there are 1 VG and 3 PSTN for 3 different child company and this works with CUCM. We want to implement it so that Webex Calling can do the same thing. There are no documentation of this ever been successful, I could not find any. But my team found a documentation that says utilizing the dial peer-configuration could solve this problem, then they made a solution configuration based off the document (https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf) page 18. We have no way of knowing if this will work or not, anyone has done this and suceeded? Thanks in advance.

[Jonathan Schulenberg]

The constraint is a single PSTN path per-logical location in Control Hub. So yes, this is possible.

If the actual PSTN circuits will remain on-prem using the Local Gateway approach you have at least two options:

• Configure separate locations and trunks in WCH, one per-subsidiary, and then use dial-peer groups on the gateway to dictate the outgoing dial-peer based on the incoming dial-peer of a call. This will likely require unique interfaces though (loopback is a valid option) so there are separate TCP sockets per-trunk. Maybe also unique certs if you don’t use the registration approach; I haven’t tried that.
• Use a single trunk in control hub with either a single location or per-subsidiary location and sort it out on CUBE instead. The incoming dial-peer would probably need to match based on answer address (ANI) instead of the newer and more definitive SIP URI method though. From there you could use dial-peer groups to dictate the outgoing DP.

Note that Survivability Gateways are limited to a single location, so consider that constraint if you need fallback. I’m not sure you could maintain PSTN separation during SGW fallback though; I haven’t needed to think through that.

If the intent is to migrate to a Cloud Connect PSTN provider to eliminate the on-prem dependency, each subsidiary intends to use the same provider, AND have separate accounts/contracts you will need to check with the provider if they can support that. Same provider account or different providers per-location would be an easy yes.