This topic describes how CCD works for on-net calls and how CCD reroutes calls to the PSTN if the IP path is not available.
The figure shows the CCD base configuration. There are two sites, each with a Cisco Unified Communications Manager cluster. One site (HQ in the figure) is located in Germany, and it has a DID range of +498953121XXXX. Internally, range 2XXX is used. The other site (BR) is in the United States; it has a DID range of +1972555XXXX. Internally, the directory number range 4XXX is used.
CCD: Propagation of HQ Routes
This section describes how HQ routes are propagated to the BR site.
The Cisco Unified Communications Manager cluster at the HQ site advertises its directory number range 2XXX with a ToDID rule of 0:+498953121 to its SAF forwarder. The SAF network propagates this new route throughout the network, and the SAF forwarder at the BR site sends the information to the BR Cisco Unified Communications Manager cluster. The call-routing table of the BR cluster is populated with the directory number pattern 2XXX and a ToDID rule of 0:+498953121.
At the advertising site, only a SIP trunk has been associated with the CCD advertising service. Therefore, the BR cluster learns the route for SIP only.
CCD: Propagation of BR Routes
This section describes how BR routes are propagated to the HQ site.
The Cisco Unified Communications Manager cluster at the BR site advertises its directory number range 4XXX with a ToDID rule of 0:+1972555 to its SAF forwarder. The SAF network propagates this new route throughout the network, and the SAF forwarder at the HQ site sends the information to the HQ Cisco Unified Communications Manager cluster. The call-routing table of the HQ cluster is populated with the directory number pattern 4XXX and a ToDID rule of 0:+1972555.
Again, only a SIP trunk has been associated with the CCD advertising service at the originating site. Therefore, the HQ cluster learns the route for SIP only.
The network is in a converged state. All sites know about the routes of all other sites.
CCD: Call from HQ to BR
This section describes the call flow for a call from the HQ site to the BR site.
The HQ site dials 4001. The called number is found in the call-routing table of the HQ Cisco Unified Communications Manager cluster.
All learned routes are put into the same configurable partition. The CSS of the calling phone must have access to this partition in order for the call to work. If the calling phone does not have access to the partition that includes all learned patterns and there is no match in any other partition, the call fails.
Cisco Unified Communications Manager identifies the matched pattern as a CCD-learned pattern. According to the learned route, the call must be set up through a SAF-enabled SIP trunk, which is dynamically created to the destination IP address as learned by CCD (in this case, 10.1.7.10).
The call is now set up over the IP network.
CCD: Link Failure at BR
This section describes how CCD manages a link failure between the SAF client and its SAF forwarder at the BR site.
When the connection between the SAF client and the SAF forwarder at the BR site is broken, the SAF forwarder at the BR site detects this problem because of the missing keepalives of the registered SAF client.
The BR SAF forwarder sends an update throughout the SAF-enabled network so that all SAF forwarders are aware that the IP path to 4XXX is currently unavailable. Other than in IP routing, the learned route is not removed, but only the IP path is marked as unreachable.
All SAF forwarders that have registered SAF clients now pass this update on to their SAF clients, so that all SAF clients in the network can mark the IP path to 4XXX as unreachable.
As shown in the figure, the call-routing table at the HQ site is also updated accordingly.
CCD: Call from HQ to BR During Link Failure
This section describes the call flow for a call from the HQ site to the BR site during a link failure at the BR site.
When a user at the HQ site dials 4001 during a link failure at the BR site, the called number is still found in the call-routing table of the HQ Cisco Unified Communications Manager cluster. However, the IP path is marked as unreachable, and therefore the call cannot be set up over the IP network by using a SIP trunk.
Cisco Unified Communications Manager now checks if there is a ToDID rule that is associated with the learned pattern. In this case, a ToDID rule of 0:+1972555 has been learned. Cisco Unified Communications Manager does not strip any digits (because of the 0 in front of the : [colon]), but it adds the prefix +1972555 to the dialed directory number 4001. The resulting number +19725554001 is now matched in the call-routing table of Cisco Unified Communications Manager, where a match is found in a PSTN route pattern.
The CSS that is used for the PSTN backup call is the AAR CSS of the calling phone. The route pattern, route list, route group, and gateway for PSTN access must be in place for the PSTN backup to work. In addition, the PSTN route pattern must be in a partition that is reachable from the AAR CSS of the calling phone.
In the example, the ToDID rule results in globalized PSTN numbers (E.164 format with a + prefix). Therefore, a PSTN route pattern that matches this format (for example, \+.!) must be in place. If all sites share the same PSTN dial rules—for example, all sites are within the NANP—then you could also configure ToDID rules that result in PSTN patterns with a PSTN access code, followed by a national access code, followed by the 10-digit PSTN number. In this case, your PSTN route pattern would have to be 91[2-9]XX[2-9]XXXXXX.
The call is now set up over the PSTN.
If the learned pattern was removed when the IP path became unavailable, the originating site would not know which PSTN number to use for the backup call. By default, a route is completely removed only if it has not advertised for 48 hours.
CCIEME 