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, firstname.lastname@example.org) 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, Cisco UBE is enhanced to route the call based on the received destination route string. Cisco UBE 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:
Dial-peer 1: London.UK.EU
Dial-peer 2: *.UK.EU
Dial-peer 3: *.EU
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.