CIPTV2 – Exam

So CIPTV2 looks to be a tough exam. This recorded webinar from Fast Lane is a real eye opener and if I’m honest scared me stiff..

You can watch the webinar here:

http://fastlane-community.com/community/webinars/previously-recorded-webinars/cisco-ccnp-collaboration-passing-the-ciptv2-300-075-exam

On the back of this I am going to home in on the ‘blueprint’ from Cisco:

300-075-ciptv2

I am going to produce a ‘mind map’ for each topic in the blueprint, with a view of detailing all the various high points about each particular topic. This will take some work, but I think will be necessary to pass the exam. Watch this space.

16.12 SAF and CCD Configuration

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.

16.11 High-Level Configuration

This topic describes the high-level configuration procedure for implementing SAF and CCD.

Configure SAF network:

  • Configure SAF forwarders on Cisco IOS routers.
    1. Specify same autonomous system on all SAF forwarders.

Implement internal SAF client:

  • Configure trunk profile with IP to use for call setup.
  • Configure directory number blocks to be advertised.
  • Configure call control profile referring to directory number blocks and trunk to be used.
  • Configure actual CCD process (channel) referring to SAF forwarder by autonomous system number.
    1. Enable advertising service by referring to call control profile.
    2. Enable requesting service.
  • Configure VoIP dial peer referring to SAF.

The first main configuration task is to enable SAF in the network. You must configure SAF forwarder functionality on a Cisco IOS router. All SAF forwarders must share the same SAF autonomous system number. You can specify the interface that should be used by the SAF forwarder.

When you use internal SAF clients, you must perform these main configuration tasks:

  1. Configure a trunk profile and specify the interface and the protocol to use for call signaling.
    Note

    The IP address (interface) that is used for call signaling can be different from the IP address that is used by the SAF forwarder.

  2. Configure the directory number blocks to be advertised.
  3. Configure a call control profile that refers to the directory number blocks and the trunk profile to be used.
  4. Configure the actual CCD process (“channel”) that refers to the SAF forwarder by its autonomous system number. Then perform these tasks:
    1. Enable the CCD advertising service by referring to the call control profile.
    2. Enable the CCD requesting service.
  5. Configure a VoIP dial peer that refers to the SAF.

Implement external SAF client:

  • Add external SAF client (Cisco Unified Communications Manager) to SAF forwarder:
    1. Specify SAF ID, username, and password of external client.
    2. Map external SAF client to SAF autonomous system.
  • Add SAF forwarder (Cisco IOS router) to SAF client (Cisco Unified Communications Manager).
    1. Specify SAF ID, username, and password as configured at SAF forwarder.
  • Configure CCD at external SAF client:
    1. Configure SAF trunks.
    2. Configure hosted directory number patterns and hosted directory number groups.
    3. Configure CCD advertising service.
    4. Configure CCD requesting service and partition for learned patterns.

When you implement external SAF clients, you must perform these high-level configuration tasks:

  1. At the SAF forwarder (Cisco IOS router), add the external SAF client (Cisco Unified Communications Manager):
    1. Specify the SAF ID, username, and password of the external client.
    2. Map the external SAF client to the SAF autonomous system.
  2. At the external SAF client (Cisco Unified Communications Manager), add the SAF forwarder (Cisco IOS router):
    1. Specify the SAF ID, username, and password as configured at the SAF forwarder.
  3. Configure CCD at the external SAF client:
    1. Configure a SAF SIP or a SAF H.323 trunk.
    2. Configure the hosted DN patterns and hosted DN groups.
    3. Configure the CCD advertising service.
    4. Configure the CCD requesting service and the partition to be used for learned patterns.

Internal SAF Client Configuration Elements

This section describes the configuration elements of an internal SAF client.

Configuration Element Name Configuration Element Function
Trunk profile profile trunk-route: Configured with interface whose IP address should be used for signaling when setting up SAF calls.
DN block profile profile dn-block: Configured with patterns to be advertised (internal number and number used for PSTN backup).
Call control profile profile callcontrol: Refers to directory number block profiles and trunk profile.
SAF client “channel” channel: Configured with SAF client ID and autonomous system. Advertising and requesting services are enabled; the advertising service refers to the call control profile.
Dial peer dial-peer voice: Configured with destination-pattern .T and session target saf. This dial peer is the incoming and outgoing dial peer for a call sent to or received from SAF trunks.

The table shows the configuration elements of an internal SAF client, their functions, and the ways that they interact with each other.

Note

You can configure the advertising service and the requesting service independently of each other.

Relationships of Internal SAF Client Configuration Elements

This section describes the relationships of internal SAF client configuration elements.

The figure illustrates how internal SAF client configuration elements relate to each other.

Note

The configuration that is shown in the figure is one that you can do multiple times, if multiple SAF forwarder processes are configured in separate autonomous systems. Each SAF client “channel” 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 and one H.323 trunk per call control profile). Only one trunk is required.

External SAF Client Configuration Elements

This section describes the configuration elements of an external SAF client.

Configuration Element Name Configuration Element Function
SAF security profile Configured with username and password. Referenced from SAF forwarder.
SAF forwarder Points to a SAF forwarder. Configured with IP address of SAF forwarder. Refers to SAF security profile.
SAF trunks One SAF SIP trunk and one SAF H.323 trunk can be configured. These trunks are not configured with a destination IP address. The rest of the configuration is similar to normal SIP and H.323 trunks.
Hosted DN group Configured with PSTN failover strip digits and PSTN failover prepend digits. Refers to hosted directory number patterns.
Hosted DN pattern Directory number or directory number range to be advertised. Configured with PSTN failover strip digits and PSTN failover prepend digits; if not configured, hosted directory number group configuration is used. Applied to hosted directory number group.
Configuration Element Name Configuration Element Function
CCD advertising service Refers to hosted directory number group, SAF SIP trunk, and SAF H.323 trunk.
CCD requesting service Configured with route partition, learned pattern prefix, and PSTN prefix. Refers to SAF trunks.
Blocked learned patterns Configured with remote IP, remote call control identity, and learned pattern or learned prefix.

The tables show the configuration elements of an external SAF client, their functions, and the ways that they interact with each other.

Note

You can configure the CCD advertising service and the CCD requesting service independently of each other.

The configuration of blocked learned patterns is optional.

Relationship of External SAF Client Configuration Elements

This section describes the relationship of external SAF client configuration elements.

The figure illustrates how external SAF client configuration elements relate to each other.

Note

You can configure only a single CCD requesting service in your cluster. You can configure multiple blocked learned patterns, SAF forwarders, and SAF security profiles. You can configure one CCD SIP trunk and one CCD H.323 trunk. Only one trunk is required.

16.10 Considerations When Using Clustering over the WAN

This topic describes what needs to be considered when you use clustering over the WAN.

  • Basic configuration mode:
    1. All Cisco Unified Communications Manager servers use the same primary or secondary SAF forwarders.
  • Advanced configuration mode:
    1. Multiple sets of forwarders can be configured and individually applied to Cisco Unified Communications Manager servers.
    2. This mode is required when clustering over the WAN is used.

When you configure a Cisco Unified Communications Manager cluster with one or more SAF forwarders, by default, all Cisco Unified Communications Manager nodes that are applied to the SAF-enabled trunk or trunks via the device pool will register with the configured SAF forwarder.

First, you must make sure that each local node uses a different SAF client ID. You can easily check the nodes by using a SAF client name that ends with @. In this case, each node will utilize the configured name that is followed by @ and a unique node ID. At the SAF forwarder, you must add the basename keyword to the end of the SAF external-client client-ID command, or you must manually configure all names that are used by the nodes in your cluster.

In some cases, you may not want all nodes that should use SAF to register with all configured SAF forwarders. For example, as shown in the figure, when you use clustering over the WAN, you typically want to register nodes with their local SAF forwarders only. For that configuration, click the Show Advanced link at the SAF forwarder configuration page.

At the advanced configuration mode page, you can associate individual members of the cluster selectively with the configured SAF forwarders.

16.9 Trunk Considerations

This topic describes the important considerations for when you configure CCD trunks.

  • One SAF SIP trunk and one SAF H.323 trunk can be configured for CCD.
  • If both are configured, load sharing occurs.
  • With globalized call routing, PSTN numbers are to be dialed in +E.164 format.
    1. TEHO calls received via SAF are assumed to have + in called number.
    2. Hosted directory number is in globalized format with + prefix.
  • H.323 trunks do not send + (+ is stripped).
    1. Requires incoming called-party prefix to be configured at H.323 trunk (prefix +).
    2. Otherwise, received TEHO call cannot be routed out to PSTN.
      • Difficult to troubleshoot when H.323 and SIP trunks are configured for SAF.
      • Half of the calls work (SIP), and half of the calls fail (H.323).

As mentioned earlier, you can configure one SAF-enabled SIP trunk or one SAF-enabled H.323 trunk in Cisco Unified Communications Manager and in Cisco IOS Software. If both types of trunk are used by the advertising SAF client and both are used at the requesting SAF client, then all routes are learned twice—once per protocol. When placing a call to such a route, load sharing occurs, which means that half of the calls are set up using SIP and half of the calls are signaled by H.323.

H.323 trunks, however, do not send the + sign. When a call is received (or placed) through an H.323 trunk and the called number includes a +, the + sign is stripped. The + sign is not stripped on SIP trunks.

When you rely on the + to be received through the H.323 trunk, you must configure incoming called-party settings at the H.323 trunk. Consequently, the + is prefixed before the received called-party number is matched in the call-routing table without the +.

If you have a SIP trunk and an H.323 trunk, and you do not prefix the + at the H.323 trunk, due to the load-sharing algorithm, every second call would fail (H.323) while the other half of the calls would work (SIP). These kinds of errors seem inconsistent and are difficult to troubleshoot.

Note

When you expect to receive VoIP calls to internal directory numbers and to globalized (PSTN) numbers, make sure that your incoming called-party settings prefix only the + to the called numbers where it is required. You can either refer to the ISDN type of number or use global transformations to control which called-party numbers you can modify.

16.8 Considerations When Using Globalized Call Routing

This topic describes what needs to be considered when using globalized call routing.

Cisco IOS internal SAF clients have limited support for the + sign when advertising patterns:

  • Solution for PSTN backup of internal directory number:
    1. Advertise PSTN backup number in E.164 format without +.
    2. Add + by translation pattern used for AAR calls to numbers that do not start with +.
Cisco IOS Configuration DN Pattern and ToDID Limitation
profile dn-block 1 alias-prefix 1972555 pattern 1 type extension 4XXX 4XXX 0:1972555
  • The + is not supported in alias-prefix or extension.
  • PSTN backup cannot be advertised with +.
profile dn-block 2 pattern 1 type global 14087071222 +14087071222 (no ToDID)
  • The + is added to patterns configured with type global.
  • Global patterns always have ToDID unset.
  • There is no PSTN backup for global patterns.

Cisco IOS internal SAF clients have limited support regarding the plus sign (+) in advertised routes. In fact, the + sign cannot be configured in either the DN pattern or the ToDID rule. The only way to advertise a pattern with the + sign is to use the pattern tag type global command instead of the pattern tag type extensioncommand. In this case, however, the ToDID is always unset, regardless of the configured alias prefix at the directory number block profile.

When a CCD-enabled Cisco Unified Communications Manager uses globalized call routing for PSTN access, the mentioned limitation of Cisco IOS internal SAF clients causes issues because the backup PSTN number is not in a format that Cisco Unified Communications Manager can route to the PSTN.

The workaround is to make sure that CCD PSTN backup calls can be routed to the PSTN even if the number that results from the ToDID rule does not start with the + sign.

Note

Cisco IOS Software has limitations only in advertising patterns that include the + sign. Cisco IOS Software can process received patterns that include a + sign without any problems or limitations.

Solution for PSTN Backup Advertised in E.164 Format Without Leading +

This section describes the workaround for CCD PSTN backup calls to PSTN destinations that are in E.164format without a + prefix.

It would be very cumbersome to add all possible E.164 numbers to the overall dial plan of Cisco Unified Communications Manager. However, because CCD PSTN backup calls are always placed with the use of theAAR CSS of the calling phone, you can add one translation pattern ! to a partition that is accessible from the AAR CSS only. At that pattern, you can prefix a + to the called-party number and set the CSS of the translation pattern to a CSS that has access to the global PSTN route pattern (\+!).

That process solves the issue with CCD PSTN backup calls. However, if AAR is enabled, prefixing a + will break AAR, assuming that the AAR implementation is based on globalized call routing. If the external phone number mask of the destination phone is in E.164 format with a + prefix, then AAR calls would not work anymore because AAR calls use the same CSS and therefore would also match the ! translation pattern that prefixes a +. In this case, AAR calls would be placed to E.164 numbers with two + signs. To also make AAR CSS calls work, you must add a second translation pattern in the same partition that is accessible from the AAR CSS only. This second translation pattern \+! is not configured with any digit manipulation but uses the same CSS as the other translation pattern (!). As a consequence, AAR calls are passed on to the \+! route pattern without any digit manipulation (by matching the more specific \+! translation pattern, which does not prefix a +). CCD PSTN backup calls do not match the \+! translation pattern and are therefore routes.

Note

The described solution is a workaround only. The implementation of advertised patterns in Cisco IOS Software may be changed in the future so that + can be configured in the advertised pattern and in the ToDID rule. If so, you should change from the described workaround to the solution that allows CCD PSTN backup calls to be placed to globalized numbers.

TEHO Considerations

This section describes how CCD can be used to advertise TEHO routes.

  • TEHO destinations are located at the PSTN and do not exist internally.
  • Advertised hosted DN is PSTN destination and not internal DN.
    1. If SAF-learned TEHO route becomes unavailable, ToDID number is used for automatic backup call.
    2. Typically, both numbers are identical (ToDID rule is 0:) and use +E.164 format.
  • If no ToDID is advertised, call fails until learned TEHO route is completely removed.
  • Learned route is removed only after expiration of CCD PSTN Failover Duration timer (default: 48 hours).
  • Cisco IOS Software can advertise + only in global patterns (which do not support ToDID).
  • Avoid the use of global patterns in Cisco IOS Software.
    1. If + is required for TEHO implementation and local backup is desired, do not advertise TEHO routes at sites that use internal SAF clients.

TEHO destinations are located at the PSTN only; they do not exist internally at all. The advertised directory number is a PSTN number. When globalized call routing is enabled, this number must be in E.164 format with a + prefix.

Calls to PSTN destinations will match the learned directory number and are therefore sent to the TEHO site over the IP WAN. If the IP WAN is down, the local gateway should be used as a backup. This situation requires a ToDID rule of 0:. With this rule, the CCD PSTN backup number is identical to the learned directory number. When the IP path is marked as unreachable, the same number would be called using the AAR CSS of the calling phone.

Check the Use Hosted DN as PSTN Failover check box in Cisco Unified Communications Manager to generate a ToDID rule of 0:. In Cisco IOS Software, you cannot set the ToDID to 0:.

In addition, if globalized call routing is used, you are forced to use global patterns, which do not allow you to advertise any ToDID rule.

When a TEHO pattern is advertised without a ToDID rule, the local TEHO backup does not work. You can configure only static local backup routes by putting similar patterns into partitions that are listed later in the phone CSS. However, such patterns are used only after the learned pattern has been purged completely. By default, this process occurs after the expiration of the CCD PSTN Failover Duration timer, which is 48 hours by default.

Based on these issues, it is recommended that you not advertise TEHO patterns from Cisco IOS Software if the + is required and local backup is desired.

16.7 Cisco Unified SRST Considerations

This topic describes how CCD can be implemented at Cisco Unified SRST gateways.

A Cisco Unified SRST gateway does not need to advertise any internal directory numbers because the SRST site is reachable only via the PSTN. It is the responsibility of Cisco Unified Communications Manager to know how to route calls to cluster-internal directory numbers when they are not reachable over the IP WAN.

However, the Cisco Unified SRST gateway needs a local dial plan that allows end users to place calls to other sites by dialing the internal directory number of the other site. Cisco Unified SRST then must transform the internally used directory numbers to the corresponding PSTN numbers so that the call can be rerouted over the PSTN. You do not have to configure this local dial plan manually when CCD is used. Instead, Cisco Unified SRST can subscribe to SAF and hence learn all internally known DN ranges and the corresponding ToDID rules. Cisco Unified SRST learns these routes while there is no network problem. The learned patterns are not used then because the Cisco Unified SRST gateway does not route any calls. Cisco Unified Communications Manager is in control of all IP phones and performs call-routing services.

Once IP connectivity is broken, IP phones fall back to the Cisco Unified SRST gateway, and once registered, the Cisco Unified SRST gateway must route calls. Because the gateway has learned all available internally used directory numbers with the corresponding ToDID rules, it can now route to the respective PSTN number any calls that are based on the dialed internal directory number.

In the example, the Cisco Unified SRST gateway learned three patterns while IP connectivity was working: 8408XXXX with a ToDID rule of 4:+1408555, 8415XXXX with a ToDID rule of 4:+1415777, and 8949XXXX with a ToDID rule of 4:+1949222.

When a user dials 89491000 while the gateway is in SRST mode, the IP path is marked as unreachable due to the loss of IP connectivity. Therefore, the ToDID rule is applied. It strips the first four digits and then adds the prefix +1949222 so that the number that is used for the PSTN backup call is +19492221000.

The only static configuration that is required at the Cisco Unified SRST gateway is an outbound dial peer that routes calls starting with a plus sign (+) toward the PSTN.