This topic describes the characteristics of CCD and how CCD forwarding and requesting of services occur in Cisco Unified Communications Manager.
CCD is a function of call agents. CCD allows call agents to advertise locally known internal directory numbers and the corresponding PSTN numbers to other CCD-enabled call agents. CCD utilizes SAF for distributing call-routing information over the SAF-enabled network.
A CCD-enabled call agent is configured to send its locally configured directory number range as a SAF service to a SAF forwarder. The CCD SAF client generates SAF service data (call reachability information) and passes it on to the SAF forwarder that will propagate the information within the SAF network. All SAF forwarders that have SAF subscribing clients that are attached send the SAF service data to their clients. From a CCD perspective, all SAF clients exchange SAF service data (call-routing information).
You can compare the SAF service data with the TCP or the UDP, which establishes an end-to-end communication between IP endpoints. Likewise, CCD-enabled call agents exchange call-routing information via the end-to-end service data exchange.
The SAF header can be compared to the IP header. It is also interpreted at intermediate nodes (SAF forwarders), but these intermediate network nodes do not process the payload (that is, the SAF service data).
Main Characteristics of CCD
This section explains the main characteristics of CCD.
- Enables call agents to exchange call-routing information:
- Dial plan information
- Reachability information (IP addresses of call agents)
- Allows dynamic routing based on information learned through SAF:
- No need for full-meshed call-routing configuration
- No need for centralized gatekeepers
- Only local number ranges that should be advertised must be configured
- Propagated dial plan information has two components:
- Enterprise-owned, internally used numbers
- External (PSTN) numbers for PSTN backup
- Simplifies dial plan implementation in large networks
CCD enables call agents to exchange call-routing information. The information that is relevant consists of the following:
- Dial plan information: Dial plan information includes internally used directory numbers (potentially with internal prefixes such as site codes), the IP addresses of the respective call agents, and the signaling protocol that will be used by the call agents. All of this information is advertised by call agents and propagated throughout the network by SAF and then learned by other call agents.
- Reachability information: This dynamic routing of call reachability information drastically simplifies dial plan implementations in large networks. There is no need for a static full-mesh configuration and no need even for the configuration of a centralized call-routing service (such as an H.323 gatekeeper or a SIP network service). You must configure only the internal number range that should be advertised per call agent at the respective call agent. CCD and SAF then ensure that the locally known numbers are distributed among all call agents.
When you want to reroute over the PSTN, call agents are configured to advertise their internally used number ranges and the corresponding PSTN numbers. The PSTN number is not advertised as a distinct number. The PSTN number is advertised by a PSTN failover digit transformation rule that is known as a ToDID rule.
ToDID stands for to direct-inward dialing and this term is also a GUI element in Cisco Unified Communications Manager.
A ToDID rule describes how the internally used number must be manipulated to get to the associated PSTN number. A ToDID rule consists of two components:
- Number of digits to be stripped: The first part of a ToDID rule is the number of digits that are stripped from the internally used number. For example, if site code dialing is used and the internally used number to reach a block of directory numbers is 8-408-2XXX, you may want to strip the leading 8408 before prefixing the necessary digits to directory number range 2XXX. In this case, your ToDID rule would start with 4: (because the four leading digits should be stripped).
- Prefix to be added to the (deflated) internal number: The second part of a ToDID rule is the prefix that should be added to the internally used number after digit stripping has been performed. In the previous example, if the PSTN DID range of the internally used directory number range 2XXX (dialed as 8-408-2XXX from other sites) is 408 555-2XXX, the prefix would be 408555. Usually the E.164 format with a + prefix represents the PSTN number, so the configured prefix would be +140855.
In the given example, the complete ToDID rule would be 4:+1408555; the numbers to be stripped and the prefix are separated by a colon.
By advertising only the locally present internal numbers and the corresponding ToDID rule at each call agent, the dial plan implementation of large networks is simplified. If there are any changes at a call agent, you must change only the advertised number (range) and its ToDID rule at the affected call agent. All other call agents will learn the changes dynamically.
CCD Services in Cisco Unified Communications Manager
This section describes the two CCD services that exist in a call agent such as Cisco Unified Communications Manager.
- Responsible for advertising the following:
- Hosted directory number ranges
- PSTN failover information (ToDID rule)
- Trunk information
- Configured with one or two trunks (one SAF CCD SIP trunk and one SAF-enabled H.323 ICT supported)
- Responsible for learning directory number ranges from the SAF network
- Exists only once per Cisco Unified Communications Manager cluster
- Configured with one or two trunks (one SAF CCD SIP trunk and one SAF-enabled H.323 ICT)
The CCD advertising service is configured with the directory numbers that are to be advertised. In Cisco Unified Communications Manager, the directory numbers are configured by hosted DN ranges. Each hosted DN range is configured with its PSTN failover information (the ToDID rule for the hosted DN range). In addition, the signaling protocol and the IP addresses of the call agents must be advertised. The signaling protocol and the IP addresses of the call agents are defined by the configured trunk. The trunk can be a SAF-enabled H.323 ICT or a SAF CCD SIP trunk. CCD advertises call routes with one or more call agent IP addresses. The IP addresses to be advertised are determined by the device pool that is applied to the SAF-enabled trunk.
The trunk is not used to advertise call routes. Call routes are advertised by CCD and SAF and not via H.323 or SIP. The trunk is used to determine the IP addresses of the call agents and the supported signaling protocols, in case another call agent wants to establish a call to a learned call route.
The CCD requesting service is responsible for subscribing to call-routing information from its SAF forwarder. The CCD requesting service allows Cisco Unified Communications Manager to learn routes from the SAF-enabled network. Only one CCD requesting service exists per Cisco Unified Communications Manager cluster. However, like the advertising service, the requesting service can be configured to accept patterns that are reachable via SIP or H.323, depending on the associated trunk or trunks.
Like the trunks that are associated with CCD advertising services, the trunks that are associated with the CCD requesting service are not used to learn patterns via SIP or H.323. These trunks determine the outbound capabilities for calls that are placed to learned destinations. If the CCD requesting service is associated with an H.323 trunk only, learned routes that are to be reached via SIP are not added to the call-routing table of the receiving Cisco Unified Communications Manager.
The Cisco Unified Communications Manager nodes of the cluster that is permitted to place outbound calls to learned routes are determined by the device pool that is applied to the trunk that is associated with the CCD requesting service.
Processing Received Routes in Cisco Unified Communications Manager
This section describes how received routes are processed in Cisco Unified Communications Manager.
Administrator can block received routes based on the following:
- Learned pattern prefix
- Learned pattern
- Remote call control identity
- Remote IP
Load balancing occurs for learned routes:
- Round robin between protocols, among local trunks (SIP and H.323), and learned remote IP addresses
Partitions and CSSs:
- All learned patterns in one configurable partition
- All devices that should access learned routes need access to that partition from their CSS
- AAR CSS is used for PSTN backup calls
You can configure a filter that is applied to received routes in order to deny the learning of routes, using these criteria:
- Learned pattern prefix: The received patterns are compared with the configured prefix, starting with the left-most digit. By using a learned pattern prefix for blocking received routes, you can filter internally used numbers by their leading digits—for example, by their site code.
- 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.
- 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.
You can configure one or more criteria when setting up a filter. However, as soon as one criterion is matched, the learned route is filtered.
The same destination number can be learned multiple times. It may be advertised by different call agents. It may allow SIP and H.323 to be used for setting up the call (both signaling protocol capabilities are advertised separately). It also may be reachable at multiple IP addresses (of the same call agent, in the case of a Cisco Unified Communications Manager cluster). If a route is learned multiple times, Cisco Unified Communications Manager will load-share the outbound calls to the corresponding destination among all possible paths (that is, by protocol and remote IP addresses).
All learned routes are put into one configurable partition. All devices that should have access to learned routes must have that partition in their CSS. Sometimes the IP path for a learned route may not be available, and a ToDID rule may have been advertised with the hosted directory number. In that situation, a call to the transformed number (a ToDID rule that is applied to the advertised pattern) is placed with the AAR CSS of the calling device.
PSTN backup for CCD is independent from AAR. AAR is used to place PSTN backup calls for destinations within a cluster when the IP path cannot be used because of insufficient bandwidth as indicated by CAC.
It is only the AAR CSS that is reused for CCD PSTN backup. Otherwise, CCD PSTN backup does not interact with AAR at all. For example, CCD PSTN backup works even when AAR is globally disabled by the corresponding Cisco CallManager service parameter.
Make sure that the AAR CSS is set at all phones, so that PSTN backup calls for CCD-learned patterns will work. Also ensure that the number that is composed of the directory number pattern and the ToDID rule is routable (in other words, a route pattern that matches the number exists).