15.6 Directory URI Exchange

This topic describes how to exchange directory URIs across clusters.

URI Dialing Characteristics

  • URIs are associated with directory numbers.
    1. They can be configured to be advertised by ILS.
  • URI dialing in Cisco Unified Communications Manager is case-sensitive.
    1. You can change the URI Lookup Policy enterprise parameter to Case-Insensitive.
  • The OTLD is added to calls that are placed to URIs that do not have the @ symbol and host portion.

URIs are associated with directory numbers and you can configure them to be advertised by the ILS.

By default, URI dialing is case-sensitive to the user portion of the URI. You can set the URI Lookup Policy parameter to Case-Insensitive by setting the corresponding enterprise parameter.

If you set the OTLD (by default, it is unset), then the configured OTLD is added to calls that are placed to URIs that do not have the @ symbol and a host portion.

Routing URI Calls to Remote SIP Call Control Systems

This section describes how Cisco Unified Communications Manager routes URI calls after a match is found in aSIP route pattern.

When the URI call-routing process finds a match in a SIP route pattern, the call is sent to a remote SIP call control system as follows:

  • The SIP route pattern is configured with the destination host portion by one of the following methods:
    1. Domain routing with an IPv4 pattern, which is the destination host portion specified as the FQDN.
    2. IP address routing with an IPv4 or IPv6 pattern, which is the destination host portion specified as the IP address.
  • The SIP route pattern refers directly to a SIP trunk or terminates at a SIP trunk through a route list and route group construct.
  • The SIP trunk refers to one or more destinations by IP address or FQDN or as DNS SRV entry.
  • The same SIP trunk can be used for numeric and nonnumeric calls.

When the URI call-routing process finds a match for the called host portion of a URI or of the ILS route string in a SIP route pattern, then the call is sent to a remote SIP call control system.

The SIP route pattern can be configured as an IP address or, more likely, as an FQDN. When you configure a SIP route pattern as an IP address, you must set the Pattern Usage to IP Address Routing. When you configure a SIP route pattern as an FQDN, you must choose Pattern Usage Domain Routing.

You can configure a SIP route pattern to refer directly to a SIP trunk, or you can use the route list and route group construct. You must use the route list and route group construct when multiple SIP trunks should be used for load-sharing or backup purposes.

Each SIP trunk refers to one or more destinations by IP address or FQDN. In the case of an FQDN, the FQDN is not only a domain (like in a SIP route pattern), but also the FQDN of a host, specifically the host of the remote call control server. You can configure more than one destination per SIP trunk. If the remote call control system is a Cisco Unified Communications Manager cluster, you must configure all members of the remote cluster that can control the interconnecting SIP trunk. If you omit a remote server, your cluster will not accept incoming calls from that unknown host.

Alternatively, a SIP trunk can be configured to use DNS name resolution by requesting the SIP SRVs of the specified SIP service name. To enable DNS SRVs at SIP trunks, check the Destination Address Is an SRV check box and enter the target SIP service name in the Destination Address field. When you check the Destination Is an SRV check box, you can specify only one destination address. Redundancy is provided by the DNS server in this case.

You can use the same SIP trunk for numeric and non-numeric calls.

Factors Influencing URI Call Routing

The URI call-routing process is rather complex and depends on several conditions.

Calls to URIs are routed differently depending on their type:

  • Numeric versus nonnumeric depends on the SIP Profile parameter Dial String Interpretation:
    1. All dial strings always treated as URI addresses
    2. Phone number consists of characters 0–9, A–D, *, #, and + (others treated as URI addresses)
    3. Phone number consists of characters 0–9, *, #, and + (others treated as URI addresses)
  • If numeric, local versus remote:
    1. A numeric URI is considered to be local if the host portion matches one of the following:
      • IP address of any cluster member
      • CFQDN enterprise parameter
      • OTLD enterprise parameter

The first thing that is checked is whether the user portion of the called URI is numeric. The SIP profile Dial String Interpretation parameter specifies when a called URI is considered to be numeric.

The service parameter can be set to one of the following options:

  • All dial strings treated as URI addresses
  • Phone number consists of characters 0–9, A–D, *, #, and + (others treated as URI addresses)
  • Phone number consists of characters 0–9, *, #, and + (others treated as URI addresses)

In the call-routing flow, if a URI is considered to be numeric, then further processing differs for local versus remote URIs. A pattern is considered to be local when one of the following conditions applies:

  • The host portion of the URI matches the IP address of a cluster member.
  • The host portion of the URI matches the CFQDN.
  • The host portion of the URI matches the OTLD.
Note

The CFQDN and the OTLD are enterprise parameters.

URI Call-Routing Process

The figure illustrates the complete URI call-routing process.

Non-Numeric URI Call-Routing Process

When a SIP call is placed to a URI, and the user portion of the called URI is not a number, then Cisco Unified Communications Manager will route the call as follows:

  1. The full URI is looked up in the URI routing table, which contains all locally configured directory URIs (URIs that are applied to directory numbers at the Directory Number Configuration page or via an end user). If a match is found, then the call is sent to the corresponding phone line.
    Note

    This lookup follows the CSS and partition logic. Like directory numbers, a partition can be assigned to a directory URI. There is no separate CSS for URI routing. The CSS that is used for numeric call routing is also applicable to URI routing.

    SIP route patterns and ILS-learned URIs are ignored at this stage.

  2. If no match is found, then the full URI is looked up against the ILS-learned URIs.
    Note

    The lookup against the ILS-learned URIs always considers all ILS-learned URIs. ILS-learned URIs do not have an assigned partition, and the CSS and partition logic does not apply to lookups against ILS-learned URIs.

  3. If the full URI matches an ILS-learned URI, then the associated route string is matched against all accessible SIP route patterns. If no matching SIP route pattern is found, then the host part of the originally called URI is looked up against all accessible SIP route patterns.
  4. If the full URI does not match an ILS-learned URI, then the host part of the originally called URI is looked up against all accessible SIP route patterns.
    Note

    A partition can be assigned to a SIP route pattern. When a route string or the host part of a called URI is matched against the SIP route patterns, the CSS and partition logic applies. SIP route patterns in partitions that are not included in the CSS of the calling devices are ignored.

  5. If a matching SIP route pattern is found, then the call is routed by using the matched SIP route pattern. If no matching SIP route pattern is found, then the call fails.

In summary, the non-numeric URI call-routing process depends on the CSS and partitions (when looking up locally configured full URIs and SIP route patterns), but the priorities also depend on the type of lookup. The full URI is first searched in local URI entries. ILS-learned patterns are searched next (without involving any CSS and partitions), and SIP route patterns are searched with the lowest priority.

Numeric URI Call-Routing Process

When a SIP call is placed to a URI, and the user portion of the called URI is a number, then Cisco Unified Communications Manager routes the call based on the rules for numeric URI call routing. The rules for numeric URI call routing include the following steps:

  1. If the host portion of the called URI is the IP address of a cluster member or matches the CFQDN, then the user portion of the URI is looked up in the accessible partitions of the numbered call-routing table. If a match is found, then the call is routed to the matched entry. If no match is found, then the call fails.
    Note

    This lookup follows the CSS and partition logic.

  2. If the host portion of the called URI matches the OTLD, then the user portion of the URI is looked up in the accessible partitions of the numbered call-routing table. If a match is found, then the call is routed to the matched entry.
    Note

    This lookup follows the CSS and partition logic.

  3. The host portion of the called URI is looked up against the accessible SIP route patterns. If a match is found, then the call is routed using the matched SIP route pattern. If no matching SIP route pattern is found, then the call fails.
    Note

    All three described lookups follow the CSS and partition logic.

ILS-Based URI Exchange

ILS can be used to propagate and learn URIs and associated route strings.

  • ILS propagates and learns URIs and associated route strings.
  • ILS propagation is enabled per configured URI.
  • Each cluster builds a complete list of URIs and associated route strings.
    1. Stored in configuration database, replicated to subscribers
    2. Used by URI call-routing process if no local match is found

The propagation of a URI is configured per URI at the directory number configuration page. This approach also applies to directory URIs that are assigned via an end user.

Each participating cluster builds a complete list of all URIs and the associated route strings. Learned URIs and route strings are stored in the configuration database.

The ILS-learned URIs are used by the URI call-routing process, if no local match for the called URI is found.

ILS-Based Multicluster URI Routing Example

When user1@cisco.com calls user2@cisco.com, the following happens:

  • URI is not found locally using CSS and partitions.
  • Match in ILS table is found; associated route string is emea.cisco.com.
  • SIP route pattern for emea.cisco.com exists and is matched; call is routed via associated SIP trunk.

The example in the figure illustrates the URI routing process in an ILS-enabled multicluster deployment.

The figure shows two clusters that are part of an ILS network. URI syncing is enabled, and URIs and route strings have been exchanged. When user1@cisco.com calls user2@cisco.com, the following URI routing process occurs:

  1. The full called URI is looked up in the local URI routing table. The CSS of the calling device is used to determine which partitions of the URI call-routing table are considered in the lookup. In the example, the called URI does not exist in the local cluster URI routing table.
  2. The full called URI is looked up in the ILS URI routing table. This lookup does not utilize the CSS of the calling device because ILS URIs do not have an assigned partition. When the ILS URI routing table is searched, all patterns are subject to the search. In the example, a match is found. The matched ILS URI entry, user2@cisco.com, is associated with the route string emea.cisco.com.
  3. The route string that is associated with the matched ILS URI entry (emea.cisco.com) is matched against all configured SIP route patterns. In the example, a SIP route pattern for emea.cisco.com is found, and the call is routed according to the SIP route pattern. The CSS of the calling device is used to determine which partitions of the SIP route pattern table are considered in the lookup.

Using Session Management Edition in an ILS Network

You can deploy Cisco Unified Communications Manager Session Management Edition to simplify the SIP route pattern and SIP trunk configuration.

The Cisco Unified Communications Manager Session Management Edition cluster should be configured as an ILS hub, and all leaf clusters should be configured as ILS spokes. Each ILS spoke is configured with a unique route string.

The SIP route pattern configuration at the spokes is very simple. Each cluster has a single SIP route pattern (see the asterisk [*] in the figure), which refers to the only configured SIP trunk that points to the Cisco Unified Communications Manager Session Management Edition cluster. At the Cisco Unified Communications Manager Session Management Edition cluster, you configure one SIP route pattern and one SIP trunk per ILS spoke cluster.

The figure shows an example of an ILS network with a Cisco Unified Communications Manager Session Management Edition cluster. Only the spokes have registered endpoints, and the URIs of these endpoints are advertised with a cluster-specific route string.

URI Exchange-Related Considerations

This section describes what must be considered when you implement URI syncing and routing.

  • ILS-learned and imported URIs cannot be assigned a partition.
    1. Local URIs of accessible partitions always have priority.
    2. ILS URIs have priority over lookup of host portion in SIP route patterns.
  • ILS message exchange is independent of SIP route patterns and SIP trunks.
    1. ILS populates the URI call-routing table only.
    2. ILS is not used for actual call setups (sending INVITE messages).
    3. SIP route patterns and SIP trunks must be statically configured.
  • Since Cisco Unified Communications Manager Version 9, a SIP route pattern can refer to a route list.
    1. Allows the configuration of a prioritized list of SIP trunks.
    2. Enables configuration of backup paths.

ILS-learned and imported URIs cannot be assigned a partition. Locally configured URIs always have priority over ILS URI routing-table entries. However, locally configured URIs can be assigned a partition, and therefore not all URIs may be visible to the calling device. ILS URI routing-table entries always have priority over a lookup of the host portion against the accessible SIP route patterns. If the route string that is associated with a matched ILS URI is not found in any accessible SIP route pattern, the host portion of the URI is matched against the accessible SIP route patterns.

Note

SIP route patterns can be assigned a partition. SIP route patterns in partitions that are not included in any of the calling devices are ignored.

The ILS information exchange is independent of the signaling message exchange. ILS and URI syncing populate only the ILS URI routing table, but ILS is not used for actual call setups (sending SIP messages such as INVITE). SIP route patterns and SIP trunks must be configured to make the call setup to another cluster work, but they are not required for URI syncing to be successful.

Since Cisco Unified Communications Manager Version 9, a SIP route pattern can also refer to a route list. By referring to a route list, more than one SIP trunk can be associated with a SIP route pattern to configure backup paths.

Advertisements