A Uniform Resource Identifier (URI) is a device-independent user address. A subscriber can use a URI as a personal identity
and move from one network to another without any change in the URI. You cannot summarize URIs within an enterprise network
(for example, abc@company.com) the same way that directory number ranges are summarized.
The Intercluster Lookup Services is a dynamic mechanism to discover URIs. When it is enabled, Cisco Unified Communications
Manager users can initiate calls using URIs. The Intercluster Loookup Service provides a framework for sharing user-contact
information between Cisco Unified Communications Manager clusters. All URIs being used within a cluster are grouped together
and associated with a cluster identifier called a route string. These URI groups and their associated route strings are shared
between all other participating clusters.
While initiating a call, the URI uses the Intercluster Lookup Service to identify the target URI and associated route string
to route the call between clusters. Cisco Unified Communications Manager uses a Session Initiation Protocol (SIP) route
pattern to match the route string returned by Intercluster Lookup Service and route the call over a SIP trunk. If Intercluster
Lookup Service is enabled, the Cisco Unified Communications Manager SIP trunk sends the SIP invite message with destination
route string header information.
To interoperate with Cisco Unified Communications Manager, CUBE is enhanced to route the call based on the received destination
route string. CUBE supports exact match and wildcard match for a route string and parses the received destination route string
header and routes a call forward to the destination. The destination can be a Cisco Unified Communications Manager cluster,
public switched telephone network (PSTN), or any third-party unified communications device.
The dial-peer module is enhanced to support the dial-peer matching based on the destination route string header. The destination
route string is used to match an outbound dial peer. The match can be an exact match or wildcard match.
For example, consider London.UK.EU as the route string. The SIP dial-peer configuration is as follows:
The destination route string header and route string match are not case-sensitive. In this scenario, London.UK.EU and london.uk.eu
match dial-peer 1 and therefore, dial-peer 1 is selected for outbound process.
If call routing policies are enabled, call routing based on a destination route string takes precedence over any other routing
configurations. For example, if call routing is configured on a destination route string globally or at the dial-peer level,
the call is routed considering the destination route string. If no match is found, then the call is routed using other URLs
and header configuration options.