CFA CSS Activation Policy: What It Is, How It Works, and Why You Need to Know

NetCraftsmen®

What is the CFA CSS Activation Policy?

The Call Forward All Calling Search Space Activation Policy is a configuration parameter that was added to CUCM (post 4.x).  It can be controlled globally as it is a Cisco Call Manager (CCM) service parameter.  Likewise, it can also be controlled on a line-by-line basis.  In other words, it is a line-level configuration parameter that can be explicitly set to either use the system default or to override the default on a per-line basis.  So, what does it do?  The CFA CSS Activation Policy determines the CSS(s) that are used when CFA is activated through the Call Forward All softkey (CFwdAll) on a phone.

Why is this different from previous versions of CCM (e.g., 4.x)?

CCM 4.x and earlier did not have a configuration parameter for CFA CSS Activation Policy.  Essentially, the CFA CSS could be left blank (None) and call forwarding could still function properly.  The CCM simply concatenated the Device and Line level CSS together and the most restrictive union of those two was the effective calling party CSS for CFA.

How does the CFA CSS Activation Policy work?

The system default for this parameter is “With Configured CSS”.  This means the primary and secondary CFA CSS are used.  In other words, these parameters must be explicitly set at the line level.  If they are not, CFA will not work.  In fact, unlike the 4.x days you also cannot leave the CFA CSS blank (None).  Again, the CFA CSS (at a minimum) must be explicitly configured at the line level.

The alternative configuration for this parameter is “With Activating Device/Line CSS”.  This means that you do not have to explicitly set the primary and secondary CFA CSS for each line.  Instead, CUCM will populate these values the first time a user invokes CFA using the CFwdAll softkey.  When a user presses the CFwdAll softkey for the first time to forward their phone, the CUCM updates the primary CFA CSS to match the line level CSS and the secondary CFA CSS to match the device level CSS.  There are some special cases here as follows:

  1. If the line level CSS is not used (null), then the primary CFA CSS will be null and the secondary CFA CSS will be the device level CSS.
  2. If the device level CSS is not used (null), then primary CFA CSS will be the line level CSS and the secondary CFA CSS will be null.
  3. If the line and device level CSS are the same, the primary CFA CSS will be the line level CSS and the secondary CFA CSS will be null.

So, that’s how the CFA CSS Activation Policy works but how does it actually operate in production?

I’ve talked to a number of UC Engineers that when asked about the CFA CSS Activation Policy they could recite (almost verbatim) the Cisco documented materials on what it is and how it works (see section above).  However, when asked about actual end user and operational behavior they were a bit surprised by a thing or two.  So, this is documented behavior from testing done in my UC lab:

CCM Service Parameter configured as default: With Configured CSS

Phone 1:

Line configured to use System Default.

If the primary and secondary CSS configurations are not explicitly set, CFA is broken.  User receives fast busy on every attempt to forward.

When configured correctly, the primary CFA CSS is set to the line level CSS (in the NetCraftsmen dial plan, this is the Class of Restriction CSS).  The secondary CFA CSS is set to the device level CSS.  This configuration mimics the behavior of previous versions of CCM; however, it requires the primary and secondary CFA CSS to be explicitly configured.  Users can forward to numbers appropriately based on the union of the line and device level CSS.

Users can forward from the CCM User web page and administrators can set CFA from the CCM Admin web page without issue as the primary and secondary CFA CSS are explicitly set.

Phone 2

Line is configured to override the system default (set to Activating Device/Line CSS).

When a user forwards the phone for the first time via the CFwdAll softkey, call forwarding completes successfully.  When the line is viewed from the CCM Admin web page, the primary and secondary CFA CSS are updated to the line level and device level CSS, respectively.

When forwarding is removed, the line level settings remain intact (i.e., the forward initiated at the phone sets the primary and secondary CFA CSS for the line in the database).

Users can forward from the CCM User web page and administrators can set CFA from the CCM Admin web page without issue as the primary and secondary CFA CSS was set after the first CFwdAll softkey activation.

Phone 3

Now we start to see some surprises…so pay attention ladies and gentlemen.

Line is configured to override the system default (set to Activating Device/Line CSS).

Phone was forwarded from CUCM Admin.  Call forwarding is broken.  The CFA CSS and secondary CSS remain unchanged (i.e., ).

Phone was forwarded from CCM User.  Call forwarding is broken.  The CFA CSS and secondary CSS remain unchanged (i.e., ).

Phone was set to forward from the phone via CFwdAll softkey.  Call forwarding works and the line level configuration is changed in CUCM so that the CFA CSS and secondary CSS are set correctly.

When the forwarding is removed, the line level settings remain intact (i.e., the forward initiated at the phone sets the CFA and secondary CSS for the phone in the DB).

Users can now forward from the CCM User web page and administrators can set CFA from the CCM Admin web page without issue as the primary and secondary CFA CSS was set after the first CFwdAll softkey activation.

What this means for you and/or your customers?

First, you need to be aware of the expected behavior and account for it when upgrading CCM 4.x systems.  Some high-level considerations:

  1. If you intend to use the system default of With Configured CSS but the CFA CSS is null, then you will need to update line configurations via BAT or forwarding will not function correctly.
  2. If you intend to use Activating Device/Line configuration (either system-wide or per phone), any phones that were forwarded prior to upgrade and are migrated as such will no longer forward properly.  You (or end users) will need to remove the forwarding configuration from these phones and reactivate via the CFwdAll softkey.
  3. The Activating Device/Line configuration is ineffective for CTI devices since the database is updated after the CFwdAll softkey is invoked.  Forwarding issues carry over to CTI devices such as CTI ports as well.  If the CFA CSS (primary and/or secondary) are not explicitly configured, forwarding will be broken post-upgrade.  Use With Configured CSS for these devices and explicitly configure the primary and secondary CFA CSS.
  4. Remote workers may be best served by With Configured CSS.  Remote workers may or may not have an IP phone or soft phone (e.g., many may simply forward to a mobile or home phone).  In those cases, use With Configured CSS and explicitly configure the primary and secondary CSS.  Since these users may rely heavily on administrative forwarding or forwarding via the CCM User web page, they may not be able to invoke CFwdAll via softkey to update line level configurations in the database.
  5. For customers with dial plans that do not reflect best practices for controlling Class of Restriction via Device and Line level CSS configurations, users could potentially be allowed to forward to undesirable destinations (e.g., International, Long Distance, etc).

2 responses to “CFA CSS Activation Policy: What It Is, How It Works, and Why You Need to Know

  1. Hi David,

    Thanks for the article and knowledge sharing!

    I am curious to know your best practice for a dial plan based on Local Route groups and the behavior of CFWDAll.

    Assume all NANP patterns point to the SLRG and the CFA CSS is the same as the Line/Device(whether it’s Activating Device/Line CSS or default). If a phone in site A calls a phone in Site B, which is CfwdAll to a PSTN number, the call will egress the Site A’s Gateway, which is undesirable.

    A solution is to use site specific CSS/Patterns, RL->RG’s…but this negates the advantage of non-site specific patterns you’ve gained by using the SLRG in the first place.

    Any work around for this?

  2. It was really very helpful and informative while being straight forward and to the point.
    CFA coaching in Indore

Leave a Reply