Cisco CUCM Toll Bypass And PSTN Fallback

This article describes how I implemented Toll Bypass and PSTN fallback in CUCM and in IOS gateways.

Toll Bypass = voice calls follow the WAN and not PSTN.

PSTN fallback is the ability to route voice traffic to PSTN when the WAN gets down. I implemented it in my home lab between HQ and Branch1.

Toll Fraud Scenarios

In these sample Toll fraud scenarios, we will assume that we have the following elements:

• Destination A
• Destination B
• corporate user John.
• destination A and destination B are international numbers.

scenario 1

John calls A and puts it on hold by clicking on the “Transfer” softkey . Then he calls B and puts it on hold too with the “Transfer” softkey. He presses “Transfer” for the third time and now A is transferred to B. They communicate with each other and the call is charged on the company’s bill

scenario 2

John calls A and puts it in a conference by clicking on the “Conference” softkey. Then he calls B and puts it in the same conference. Now all three parties can hear each other and charge the communication on the company’s bill

scenario 3

This scenario build on top of the previous scenario. And if the Drop Ad Hoc Conference is set to False, then John leaves the conference. Both A and B can still communicate with each other.

Lab topology

To be able to emulate WAN failure and do PSTN fallback in my home lab, I need to have phones still up even after WAN outage. One way to do it is to implement Cisco SRST in Branch1 site.

Toll Bypass configuration

In a CUCM implementation, toll bypass is simple. All phones registered to CUCM call each other over the WAN. In my home lab, phones in branch offices register to CUCM over the WAN (OSPF).

Phones reach each other over the WAN.

PSTN fallback configuration

It makes sense to see a PSTN Fallback scenario after having seen a CUCM Toll Bypass scenario. The principle is to allow users in HQ to call the same 4-digit extensions to reach Branch 1 phone. All the intelligence must be implemented at CUCM and voice gateways to make this transparent to the end user, and it includes some digit manipulation.

PSTN fallback configuration on the Branch1 voice gateway

Branch1 voice gateway implements SRST. In addition to it, there is a dial-peer already configured that leads to a routing loop:

That’s normal because dial-peer 1200 points back to the emulated PSTN:

I needed a dial-peer of the same pattern, but pointing to the router itself, because DN 2001 is already registered to this router, as part of SRST:

I tried “session target ipv4:10.11.12.254”.

And I configured a combination of a voice translation profile and a voice translation rule to correctly represent the called party number (which is here 4048812100) in 4-digit format. That’s because, if you look at the home lab topology, you’ll notice that Branch1 has a single DID number.

Here is the configuration of the dial-peer 405:

PSTN fallback configuration on the CUCM

The trick lies here. At first, I though “I could add a route pattern 2XXX” in the internal partition. That way, whenever the DN 2001 is unregistered, the CUCM will pass to the second-matching pattern which is 2XXX.”

I was wrong. I found that CUCM does not work that way. I analyzed the call routing path with DNA and I discovered that CUCM only considers my “solution” as an alternate route:

So I thought “since the line is unregistered, why not configure a Call Forward Unregistered CFUr that forwards the call to the Branch1 DID number? and give it appropriate CSS “

I dialed x2001 from HQ phone and the call went over PSTN successfully:

HQ phone dials 2001

 

Branch1 SRST phone rings

If I bring the WAN network back online, Branch1 phone may take a while to detect connectivity to CUCM. So you can manually reset it whenever there is a change in the WAN.