One of the problems I have always had with SRST was that the CUCM was unable to identify that a whole site has gone offline and that it may possibly be in SRST mode. This is an issue (for me at least) because if someone at Site-A was trying to call a user at Site-B (that was in SRST mode) then the call would either give a busy signal or roll to voicemail. The call handling provided depended on the configuration applied to the Call Forward No Answer (CFNA) parameter assigned to the called line.
I always thought that (a) the CUCM has access to RIS data and could track/trend if programmed to do so, (b) the CUCM has an SRST reference config that could be assigned to a device pool, (c) the CUCM could be made aware that the SRST reference is a specific gateway. Armed with this type of information, CUCM should be able to deduce that a site was in SRST mode and have some special (“new”) configuration/features to handle re-routing calls to SRST sites. Prior to CFUR I was thinking about something along the lines of AAR.
With CFUR, there is now an option. It is a decent option, but it does come with some consideration as it is not specifically linked to SRST in any way. I probably would have approached it from a different perspective, but then again I don’t have a soft switch on the market now do I?
How Does It Work?
On each device line, you have multiple call forwarding options available to you such as Call Forward All (CFA), Call Forward Busy (CFB), Call Forward No Answer (CFNA), etc. CFUR is yet another call forwarding option that is engaged when a device is not registered. This is true whether:
- The phone is “unregistered”: Which means the phone had a healthy registration in the recent past,
- The phone is “unknown”: Which means the phone has never registered or the last registered status event was quite some time in the past, or
- A user device profile is not logged in
When an active directory number (station line or UDP line) is “unregistered”, a call to this line will be redirected based on the CFUR configuration. The redirection routing decision is then made based on the destination, callings search space, or voicemail flag parameters.
Using CFUR in Support of SRST
Take the following diagram as an example:
In the diagram, remote site 1 (RS1) is experiencing a WAN outage. RS1 phones are configured to use SRST and, assuming that the outage is on the network and not the RS1 router, the phone with extension 3000 is registered as an ephone. For this example, we should also assume that DIDs assigned to RS1 are provisioned on the PSTN circuit terminated at the RS1 SRST gateway (more on that later).
The phone with DN 2000 goes offhook and dials 3000 to reach the RS1 station [step 1]. Since RS1 is in SRST mode, all phones at that site have the status of “unregistered” from the CUCM cluster point of view. Given this state of affairs, the CUCM call processing node handling DN-2000’s call setup request will pass the call decision process to the ForwardManager sub-process for a call routing decision. The ForwardManager will determine that DN-3000 has a Call Forward Unregistered (CFUR) setting of “92025553000”.
Let’s assume that the CSS assigned to the CFUR configuration is valid and has a PSTN route pattern that will handle the “92025553000” digit string. The call is then redirected to the HQ voice gateway for routing to the PSTN [step 2]. The call routes through the PSTN and is presented as a DID on the RS1 voice gateway [step 3]. Finally, the ephone is registered, the SRST router is configured with appropriate translations, and the DN-3000 rings [step 4].
So, using CFUR we can accomplish something that we could not prior to the introduction of this feature. Namely, we can maintain call path continuity to an SRST enabled site from on-net (CUCM cluster) stations not located at that site.
Considerations
So, we have CFUR and all is well with the world. All of our SRST woes are solved and we can now receive accolades from our adhoring fans. Well, before you accept that award for smartest IT mind in your cube farm, make sure you take some things into consideration.
What About Non-SRST Unregistered Devices?
Good question, using the same topology in the above diagram let’s assume that the DN-3000 phone is simply unplugged from the network and that the RS1 site WAN connection is healthy. When DN-2000 places a call to 3000 [step 1], the CFUR configuration for internal calls is applied and the call is sent to the HQ voice gateway [step 2]. The call is then sent across the PSTN and received on the RS1 voice gateway [step 3]. Now what happens? If you are using the default configuration, then your call is sent back out the voice gateway and you are now in a call loop. But this is solvable.
Based on the Cisco SRND, a special service parameter was created for just this occasion. The service parameter is called MaximumForwardUnRegisteredHopstToDn. The default value is 0, which means it is disabled. A setting of 1 would stop call routing as soon as a single call is passed through the CFUR mechanism. A setting of 2 would allow two calls and so on. This method is fine, but it isn’t the only way…
This is where the “internal” and “external” call forward designation can be handy. At step 1 the CUCM sees the call from DN-2000 as an internal call and will use the CFUR-Internal parameter on DN-3000 to make the routing decision. At step 3, the call coming in is an external call and the CUCM will use the CFUR-External parameter on DN-3000 to make the routing decision. In our example, you will notice we have the CFUR-external parameter set to send the caller to voicemail. The loop is broken, no service parameter required. Though I would set it just in case someone forgets to use the CFUR-external parameter.
While this does introduce a sub-optimal call path (i.e. we use two B-channel resources to reach voicemail on an unregistered phone) it does avoid the call routing loop. It also provides a better experience than relying on the Max Forward counter as you are actually treating the call instead of giving the caller a rude busy.
What about lines that are Line Group members?
Call forwarding configurations on line group members does not come into play when that line is part of a line group and the DN called is the hunt pilot to which that line group is associated (via hunt groups). So, if you want to provide an SRST-aware solution on the hunt pilot, you need to leverage the call forwarding parameters on the pilot. There is no CFUR-like configuration available, so you have to either send callers to VM or redirect to a dedicated DID provisioned on the remote site PSTN trunks.
What if I don’t have DIDs provisioned at my remote site?
If you don’t have DIDs provisioned at the remote site you can still use CFUR. However, you won’t be able to send calls to a specific station. If you go this route, then you will need to think along the lines of using a shared line appearance on phones at the remote office or an identified “attendant” (the concept, not the feature) directory number. The net effect is that your caller would be able to reach a human being that could then manually redirect the call. Just keep in mind the “non-SRST” devices that are not registered.
What about Local Route Groups?
Local Route Group is a concept introduced in CUCM 7.x that warrants attention. We’ll have to save a deep dive discussion on Local Route Groups for another day but we’ll touch on how it can affect CFUR here.
In our example, we are redirecting On-Net callers to “92025553000” with the CFUR-Internal configuration on DN-3000. In a traditional dial plan, this pattern is handled by a route pattern, say: 9.[2-9]xx[2-9]xxxxxx.
So, how does the “Local Route Group” play a role with CFUR? Well, in our simple example it doesn’t, but assume we had 10 other sites that could call DN-3000. In the “pre-Local Route Group” approach, the CFUR Calling Search Space dictated which pattern the call was redirected to. This pattern would in turn use the “Pattern->Route List->Route Group->Gateway” relationship and direct all calls to the same gateway list. In our example, this means that all calls from all enterprise IP phones to DN-3000 that use CFUR will be redirected out the HQ voice gateway.
In a medium or large environment, this doesn’t scale so well and it adds a nasty variable to traffic engineering design. Now, with Local Route Groups the story changes. It is still true that the CFUR Calling Search Space on DN-3000 will pick the route pattern and that route pattern will point to a specific Route List. However, that route list can now have the “Standard Local Route Group” assigned to it in the first priority order. If this is true, then CUCM will use the Device Pool of the calling party and, if configured, will use a Local Route Group assigned to that phone. The net effect is that when a phone at HQ calls DN-3000, it will use the HQ voice gateway while a phone at RS10 calling DN-3000 will use the RS10 voice gateway.
Extended this concept further and adding in another CUCM 7x dial plan concept: “number globalization”, you can actually address all CFUR needs with a single route pattern and a single CSS for the entire cluster. Definitely a discussion for another day. Stay tuned.
Very nicely written.