16.12 SAF and CCD Configuration

Posted on by

This topic describes how to configure SAF and CCD.

SAF Forwarder Configuration Procedure

  1. Configure SAF forwarder.
  2. Configure SAF forwarder to support external SAF client (if used).

The configuration of the SAF forwarder consists of two steps: the SAF forwarder configuration (mandatory) and the support of an external SAF client (if used).

Step 1: Configure SAF Forwarder

The figure shows the SAF forwarder configuration.

Note

EIGRP = Enhanced Interior Gateway Routing Protocol

In the example, a SAF forwarder is configured with autonomous system 1. All SAF forwarders that should exchange information with each other must be in the same autonomous system.

You use the sf-interface command to bind the SAF process to the specified interface. If the router has multiple interfaces, it is recommended that you use a loopback interface.

Step 2: Configure SAF Forwarder to Support External SAF Clients

The figure shows how to configure a SAF forwarder to support an external SAF client.

Each allowed external client must be listed in the service-family section. In addition, the username and password that should be used by the external client must be specified in the service-family external clientsection.

Note

If you want to allow multiple nodes of a Cisco Unified Communications Manager cluster to act as SAF clients, each node must have a unique client name. You can configure each client individually with a separate node name or use a SAF client ID in Cisco Unified Communications Manager, which is client-ID@. The @ sign instructs Cisco Unified Communications Manager to add a unique node number so that the actual client IDs are client-ID@1, client-ID@2, and so on.

At the SAF forwarder, you can create individual entries or add the keyword basename to the external-client client-ID command. Do not specify the @ sign at the SAF forwarder; only add the keywordbasename to the external-client command, and the specified client ID will be permitted with any suffixes of @ followed by a number.

Current versions of Cisco IOS Software support a new command syntax for SAF and CCD in addition to the syntax that is supported by earlier versions. For backward compatibility, the older commands are shown in the example. The older commands are supported by all versions of Cisco IOS Software and the old syntax is not converted to the new syntax. However, messages that are similar to the following are displayed on current versions of Cisco IOS Software:

% "external-client" is deprecated.
% Configure "service-routing xmcp listen" instead.
% "service-family external-client" is deprecated.
% Configure "service-routing xmcp listen" instead.
Note

Despite the messages, you can still use the old command syntax. Refer to the current documentation for Cisco IOS Software for more details about the new command syntax.

External SAF Client Configuration Procedure

This section shows the configuration procedure of an external SAF client.

  1. Configure SAF security profile.
  2. Configure SAF forwarder.
  3. Configure SAF trunk.
  4. Configure hosted DN group.
  5. Configure hosted DN pattern.
  6. Configure CCD advertising service.
  7. Configure CCD requesting service and partition.
  8. Configure CCD blocked learned patterns (optional).
  9. Configure CCD feature parameters (optional).
Note

DN = directory number

The last two configuration steps are optional. You do not have to configure the CCD advertising service and the CCD requesting service if you want only to advertise or learn call routes (exclusively).

Note

All steps are performed at Cisco Unified Communications Manager.

Step 1: Configure SAF Security Profile

The figure shows how to configure a SAF security profile.

Make sure that the username and the password match the username and password that were configured at the SAF forwarder.

Step 2: Configure SAF Forwarder

The figure shows how to add a SAF forwarder to Cisco Unified Communications Manager.

The destination IP address must match the interface that is specified with the sf-interface command at the SAF forwarder.

If you want to register with more than one SAF forwarder, click the Show Advanced link. This link allows you to configure multiple SAF forwarders and to associate individual members of the cluster selectively with the configured SAF forwarders.

Note

If you want to allow multiple nodes of a Cisco Unified Communications Manager cluster to act as SAF clients, each node must have a unique client name. You can configure each client individually with a separate node name or use a SAF client ID in Cisco Unified Communications Manager, which is client-ID@. The @ sign instructs Cisco Unified Communications Manager to add a unique node number so that the actual client IDs are client-ID@1, client-ID@2, and so on.

At the SAF forwarder, you can create individual entries or add the keyword basename to the external-client client-ID command. Do not specify the @ sign at the SAF forwarder; only add the keywordbasename to the external-client command, and the specified client ID will be permitted with any suffixes of @ followed by a number.

Step 3: Configure SAF Trunk

The figure shows how to add a SAF trunk in Cisco Unified Communications Manager.

You can configure one SAF-enabled SIP trunk (as shown in the figure) and one SAF-enabled H.323 trunk. With a SAF-enabled H.323 trunk, you must first add a standard nongatekeeper-controlled ICT and then check the Enable SAF check box. Once the check box is checked, the IP address field is disabled because the configured trunk does not refer to a particular destination IP address. Instead, the trunk acts as a template for a dynamically created trunk once a SAF call is placed. The destination IP address is then taken from the learned SAF service data.

The same concept applies to the SAF-enabled SIP trunk. The only difference is that the SAF-enabled SIP trunk is a special trunk service type, which is selected before the trunk configuration page is shown. Therefore, there is no extra check box like there is at the nongatekeeper-controlled ICT. In addition, the SAF-enabled SIP trunk does not have a destination IP address field.

You can have one SAF-enabled H.323 trunk or one SAF-enabled SIP trunk.

Step 4: Configure Hosted DN Group

The figure shows the configuration of a hosted DN group in Cisco Unified Communications Manager.

The hosted DN group will be referenced from hosted DN patterns. If all—or at least most—of the associated hosted DN patterns share the same ToDID rules, you can configure the ToDID rule at the hosted DN group. The settings of the hosted DN group are applied to the hosted DN patterns if the hosted DN pattern parameters are unset.

The Use Hosted DN as PSTN Failover check box instructs Cisco Unified Communications Manager to create a ToDID rule of 0:. As a result, the number that is to be used for PSTN backup is identical to the internally used number. Usually, this result occurs only when TEHO patterns are advertised.

Step 5: Configure Hosted DN Pattern

The figure shows the configuration of a hosted DN pattern in Cisco Unified Communications Manager.

Hosted DN patterns refer to a hosted DN group. As mentioned earlier, if the parameters at the hosted DN pattern are unset, the parameters of the hosted DN group are applied. When the PSTN Failover Strip Digits field is set to 0 and the PSTN Failover Prepend Digits field is empty, both fields are considered to be unset. The configuration example that is shown in the figure does not generate a ToDID rule of 0:, but it applies the settings of the configured hosted DN group.

At the hosted DN group, the same logic applies. If the PSTN Failover Strip Digits field is set to 0 and the PSTN Failover Prepend Digits field is empty at the hosted DN pattern and at the hosted DN group, then no ToDID rule is advertised. As a result, there is no PSTN backup when the IP path is unavailable.

If you want to advertise a ToDID rule of 0:, the number that should be used for backup is identical to the internally used number (for example, when TEHO patterns are advertised). Therefore, you must check the Use Hosted DN as PSTN Failover check box.

Step 6: Configure CCD Advertising Service

The figure shows the configuration of the CCD advertising service in Cisco Unified Communications Manager.

You must configure one CCD advertising service for each configured hosted DN group. Each CCD advertising service can use the SAF-enabled SIP trunk or the SAF-enabled H.323 trunk. One trunk must be specified. Multiple CCD advertising services (and the CCD requesting service) can refer to the same SAF-enabled trunks.

Step 7: Configure CCD Requesting Service and Partition

The figure shows the configuration of the CCD requesting service in Cisco Unified Communications Manager.

You can configure one CCD requesting service only. You must enter the partition into which all learned routes should be placed. You must first create the partition as shown in the figure.

In addition to creating the partition, you can configure the CCD requesting service with a learned pattern prefix and a PSTN prefix. These prefixes are applied to all learned DN patterns and to all learned ToDID rules, respectively.

Finally, the CCD requesting service is referred to the SAF-enabled SIP trunk or to the SAF-enabled H.323 trunk.

If you associate the CCD requesting service with only one type of trunk, all received routes that are reachable by the other (unconfigured) protocol type are ignored. They are not added to the call-routing table.

Step 8: Configure CCD Blocked Learned Patterns

The figure shows the configuration of the CCD blocked learned patterns in Cisco Unified Communications Manager.

CCD blocked learned patterns are optional. If CCD blocked learned patterns are configured, all routes that match any of the configured criteria are blocked. As a result, they are not added to the call-routing table.

You can configure a filter that is applied to received routes to deny the learning of routes, using these criteria:

  • Learned pattern: The entire length of the received pattern is checked. If it matches the configured learned pattern, it will not be added to the local call-routing table.
  • Learned pattern prefix: The most significant digits of learned patterns are checked against the configured prefix. If the entire configured prefix matches the left-most digits of a learned pattern, the pattern is not added to the local call-routing table.
  • Remote call control identity: Each call agent has a SAF client ID. By setting the remote call control identity, you can filter received routes that are based on the ID of the advertising call agent.
  • Remote IP: By setting this filter, you can block routes according to the advertising IP address.

Step 9: Configure CCD Feature Parameters

The figure shows the configuration of CCD feature parameters in Cisco Unified Communications Manager.

Here are the configurable CCD feature parameters:

  • CCD Maximum Numbers of Learned Patterns: This parameter specifies the number of patterns that this Cisco Unified Communications Manager cluster can learn from the SAF network. The higher the number of allowed learned patterns, the more memory and CPU processing power that is required. Balance the need for the number of learned patterns in your system with the resources of your deployment hardware components to guide you in setting the value in this parameter. When Cisco Unified Communications Manager attempts to learn more patterns than are allowed by the value that is set in this parameter, the alarm CCDLearnedPatternLimitReached is issued. The default value is 20000.
  • CCD Learned Pattern IP Reachable Duration: This parameter specifies the number of seconds that learned patterns stay active (IP reachable) before Cisco Unified Communications Manager marks those patterns as unreachable. PSTN failover occurs when Cisco Unified Communications Manager cannot communicate with the SAF forwarder because of IP connectivity issues for the duration that is specified in this parameter. For example, this parameter is set to 20 seconds. When Cisco Unified Communications Manager cannot communicate with the SAF forwarder after more than 20 seconds, all calls to learned patterns will fail over to the PSTN according to the learned ToDID rule. PSTN failover continues until IP connectivity to the SAF forwarder is restored. Cisco Unified Communications Manager automatically detects the restored connectivity to the SAF forwarder. Cisco Unified Communications Manager then falls back to the IP path of routes as soon as the routes are received again with the appropriate reachability information. When the time that is specified by this parameter elapses, Cisco Unified Communications Manager marks the learned patterns as unreachable. If enabled, the CCD PSTN Failover Duration service parameter timer starts, which allows patterns that have been marked as unreachable through IP to instead be reached through PSTN failover. The default value is 60 seconds.
  • CCD PSTN Failover Duration: This parameter specifies the number of minutes that calls that are placed to learned patterns that have been marked unreachable are routed through PSTN failover. After this timer expired, the unreachable learned patterns are purged from the system and no PSTN failover occurs anymore. For the duration that is specified in this parameter to start counting down, another service parameter, CCD Learned Pattern IP Reachable Duration, must first have expired. The expiration of that parameter indicates that IP connectivity is down between the SAF forwarder and Cisco Unified Communications Manager and that all learned patterns are marked as unreachable. Then, when the duration in the parameter CCD PSTN Failover Duration expires, all learned patterns are purged from the system. Also, calls to purged patterns are rejected (the caller hears a reorder tone or a “This number is unavailable” announcement). Setting this parameter to 0 means that PSTN failover is disabled. If the SAF forwarder cannot be reached for the number of seconds that are defined in the CCD Learned Pattern IP Reachable Duration service parameter, and no failover options are provided through the PSTN, then calls to learned patterns will immediately fail. Setting this parameter to 525600 means that PSTN failover will never expire and, as a result, learned patterns will never be purged due to loss of communication with the SAF forwarder. The default is 2880 minutes (48 hours).
  • Issue Alarm for Duplicate Learned Patterns: This parameter determines whether Cisco Unified Communications Manager issues an alarm called DuplicateLearnedPattern when it learns duplicate patterns from different remote call control entities on the SAF network. The default value is False.
  • CCD Stop Routing on Unallocated Unassigned Number: This parameter determines whether Cisco Unified Communications Manager continues to route calls to the next learned call control entity (if advertised by multiple call agents) when the current call control entity rejects the call with the cause code for Unallocated/Unassigned Number. An unallocated number represents a hosted directory number that does not exist in the current call control entity. The default value is True.

Internal SAF Client Configuration Procedure

This section shows the configuration procedure of an internal SAF client.

  1. Configure trunk profile.
  2. Configure directory number blocks to be advertised.
  3. Configure call control profile.
  4. Configure advertising service.
  5. Configure requesting service.
  6. Configure VoIP dial peer referring to SAF.

The configuration steps that are listed in the figure are steps that you can do multiple times, if multiple SAF forwarder processes are configured in separate autonomous systems. Each SAF client channel that is configured with the advertising service and the requesting service must refer to another SAF autonomous system.

The CCD advertising service of a single SAF client channel can refer to multiple call control profiles. This capability allows the configuration of two trunk profiles (one SIP trunk and one H.323 trunk per call control profile). Only one trunk is required.

Step 1: Configure Trunk Profile

The figure shows the configuration of a trunk profile in Cisco IOS Software.

The trunk profile is configured with the interface that should be used for call signaling. The trunk profile is also configured with the protocol type (in this case, SIP) and the transport parameters (TCP versus UDP, and port number).

You can configure one SIP trunk or one H.323 trunk.

Step 2: Configure Directory Number Blocks

The figure shows the configuration of directory number blocks in Cisco IOS Software.

Each directory number block is configured globally with a ToDID that is applied to all extensions that are listed later. The command to configure a directory number block is profile dn-block tag alias ToDID-prefixstrip ToDID-strip. The subsequent command to add extensions is pattern tag type extensionpattern.

Note

The ToDID-strip argument stands for the number of digits to be stripped; the ToDID-prefix argument stands for the prefix to be added to the internal number after stripping digits.

Neither the ToDID-prefix argument nor the pattern argument supports the use of the + sign. If you want to advertise a number with a + sign, you must use the command pattern tag type global pattern. Again, you cannot enter the + sign in the pattern argument; however, due to type global, a + sign is prefixed to the configured pattern. The ToDID of global patterns is always unset.

Step 3: Configure Call Control Profile

The figure shows the configuration of the call control profile in Cisco IOS Software.

The call control profile refers to one or more directory number blocks and to a trunk. The call control profile is used in the next step to specify that the listed directory number blocks should be advertised at the specified trunk or trunks (if two of them are used). Another command that you can enter under dn-service is site-codesite-code extension-length length. This command allows a site code to be prefixed to all configured extensions that are referenced by the call control profile. The length argument sets the number of digits (starting with the least significant digit) that should be preserved from the configured extension before the site code is added.

Step 4: Configure Advertising Service

The figure shows the configuration of the advertising service in Cisco IOS Software.

You configure the advertising and requesting services under the command channel tag vrouter EIGRP-IDasystem AS. The EIGRP-ID argument refers to the name that was assigned to the router EIGRP process (SAF, in the example that is shown). The AS argument is the autonomous system number that was assigned to the EIGRP service family.

To enable the advertising service itself, you use the command publish callcontrol tag. The tag argument refers to the tag that was applied to the previously configured call control profile. Effectively, you configure the call control profile (which determines which directory numbers should be advertised by which trunk protocol) by the SAF process, which is identified by the autonomous system number.

Step 5: Configure Requesting Service

The figure shows the configuration of the requesting service in Cisco IOS Software.

You can also configure the requesting service under channel tag vrouter EIGRP-ID asystem AS. Use the subscribe callcontrol wildcarded command to enable the learning of routes that are advertised by the SAF process that matches the autonomous system number that is specified at the channel configuration level.

Step 6: Configure VoIP Dial Peer

The figure shows the configuration of a dial peer that refers to SAF-learned routes in Cisco IOS Software.

The configuration of this dial peer is like the configuration of a dial peer that refers to a session target rascommand when an H.323 gatekeeper is used. The destination pattern .T stands for all learned routes. The rest of the dial peer configuration is used as a template for the outgoing dial peer that is used on outbound SAF calls and for the incoming dial peer that is used on inbound SAF calls.

If you have other dial peers that also represent learned routes, the preference command can determine which dial peer should be treated with higher priority.