URI-Based Dial Plan for Multisite Deployments

The way in which people communicate has evolved at an exponential rate over the past few years. Fifteen years ago, had anyone heard of Facebook? Immersive video abilities were a

dream, and many organizations were using primary rate interface (PRI) as their primary means to interface with the public switched telephone network (PSTN) and their telco provider. Today, immersive video capabilities are prevalent, and instant messaging is often preferred over traditional calls. Cisco WebEx is used as a replacement to the traditional conference room, and organizations are embracing alternative ways of keeping users connected.

Today, users can be reached on multiple devices and via different technologies (voice calls, video calls, instant messages, WebEx, e-mails, and so on). From an addressing point of view, these various devices and technologies can result in lots of different user addresses and address formats. For example, many users have a direct inward dial (DID) extension, corporate e-mail address, and instant messaging usernames. Session Initiation Protocol (SIP) makes it possible to use the Uniform Resource Identifier (URI) format for addressing an end user. The URI format consists of a user and a host portion, such as an e-mail address, and provides a simple, uniform way of identifying an end user. An example of a URI is [email protected]. SIP URI dialing has been used for Internet-based video calling for years and is gaining universal

popularity. Part of the reason of the rise in popularity is that SIP URI dialing is globally routable via Domain Name Service (DNS) and friendly to end users. The traditional dial plan and +E.164 dialing are not going away anytime soon. However, it gives users another method of

communication.

Starting with Cisco Unified Communications Manager (CUCM) Release 8.6 and later, SIP-based URI dialing is now a mainstream feature that is easy to deploy within the enterprise. URI dialing is often easier for end users than having to remember long, complex telephone numbers. If you think about it, everyone remembers e-mail addresses, right? URI dialing enables elegant business reachability for voice and video calls within the enterprise and for extending beyond it. Coupling SIP-based URI dialing with a Cisco Unified Border Element (CUBE), Cisco Expressway series, or Video Communication Server (VCS) can extend URI dialing out to the Internet and perform business-to-business transactions all via URI dialing.

When implementing SIP URI dialing in a multisite or multicluster environment, route calls to other SIP-based call control systems such as a private branch exchange (PBX) or another CUCM cluster by using SIP route patterns and SIP trunks. Certain SIP parameters may have to be tuned to ensure proper operation and interoperability between different SIP call control systems.

Upon completing this chapter, you will be able to meet these objectives:

Provide an overview of URI dialing

Describe how directory URIs are assigned to an IP phone Describe how partitions and CSSs relate to directory URIs

Describe the possible sources of URI calls and related configuration elements

Describe how to support blended addressing of directory URIs and directory numbers Describe how to present remote directory URIs and directory numbers

Describe how URI calls are routed

URI Dialing Overview

Figure 4-1 depicts multiple CUCM clusters that have URI dialing enabled, along with various IP phones that are dialing via a URI-enabled dial plan.

Figure 4-1 Example of URI Dialing in a Unified Communications Environment

CUCM supports dialing by using directory URIs for call addressing. An example is if a user dials [email protected]. Rather than having to remember a lengthy on premise directory number (DN) or direct inward dial (DID) number, certain model phones and video endpoints support dialing via URI. A directory URI is a string of characters that can identify a DN.

Directory URIs look like e-mail addresses and follow the username@host format, where the host portion is an IP address or a fully qualified domain name (FQDN). It is important to remember that CUCM treats URIs as aliases for DNs. Some examples of URIs are [email protected] and [email protected].

If that DN is assigned to a phone, CUCM can route calls to that phone by using the directory URI. URI dialing is available for specific Session Initiated Protocol (SIP) and Skinny Client Control Protocol (SCCP) endpoints that support directory URIs. Not all model IP phones support URI dialing. Therefore, it is recommended to check the specific phone model’s release notes before attempting to configure URIs to ensure the feature is supported. A potential workaround solution for lack of support on certain IP phone models is to use speed dials that specify URI-based destinations.

A call to a URI behaves as if the call was made directly to a DN. The endpoint does not treat the call any differently. There is no “special ringtone” or feature enhancement for URI dialing.

However, the receiving endpoint does need to account for differences in which caller ID may be displayed. A call from an endpoint includes the URI in the caller ID when a URI is associated with a DN. Due to the lack of support for the display of directory URIs across all product lines, the DN is always included as part of the caller ID so that it can be presented when a device does not support URIs. Delivering both the URI and DN is required for callback purposes.

When designing a URI dial plan for a CUCM cluster, it is important to note that URIs are

functionally just “overlays” to existing numeric-based dial plans. It is still required to implement DNs on lines of phones and build out proper dial plans for traditional call routing.

There are some basic rules for SIP URIs inside CUCM. Once an IP phone or video endpoint is configured with a DN, up to five SIP URI aliases can be configured. One of the SIP URIs is classified as the primary SIP URI for caller ID purposes. Figure 4-2 shows the concepts previously discussed for fictitious user [email protected].

Figure 4-2 Directory URI Aliases Configured for a DN CUCM supports the following formats for directory URIs:

user@domain (for example, [email protected]) user@ip_address (for example, [email protected])

Note

Due to database restrictions in the Informix database, the directory URI field has a maximum length of 254 characters. In addition, for compatibility with third-party call control system, it is recommended to use lowercase letters for directory URIs. URI designation using the

user@domain nomenclature is the most common.

The format of the user and the host portions of a URI must follow certain rules as well. CUCM supports all the following formats in the user portion of a directory URI (the portion before the

@ symbol):

Accepted characters are a–z, A–Z, 0–9, !, $, $, %, &, *, _, +, ~, -, =, \, ?, \, ‘, comma (,), period (.), and /.

The user portion has a maximum length of 47 characters.

The user portion accepts percent encoding from %2[0–9A–F] through %7[0–9A–F].

Percent encoding refers to how special characters such as spaces or perhaps a pound symbol are stored in the IBM Informix database. The special characters are often “converted.” For example, a pound symbol (#) in a directory URI is stored in the Informix database as a %23. For some accepted characters, CUCM automatically applies percent encoding. These characters are as follows:

#, %, ^, `, {,}, |, \, :, “, <, >, [,], \, ‘, and spaces. When percent encoding is applied, the digit length of the directory URI increases.

For example, if you input joe smith#@cisco.com (20 characters) as a directory URI, CUCM stores the directory URI in the database as joe%20smith%[email protected] (24 characters).

Note

Percent encoding is also known as URL encoding. URL encoding translates special characters called reserved characters into ASCII codes preceded by a percent symbol, so that they are not interpreted as URL syntax in the URI string. For example, a forward slash (/) refers to a page in a URL, but may be included in a URI if translated into URL encoding as %2F.

Note

Due to database restrictions, CUCM rejects any attempt to save a directory URI greater than 254 characters in total length. The column in the Informix database can only hold 254 characters.

By default, the user portion of the directory URI is case sensitive. This can be changed as a service parameter inside CUCM. The URI Lookup Policy Enterprise parameter is set to case sensitive by default. Case sensitivity can often be a challenge when deploying a URI overlay to

an existing CUCM dial plan. Figure 4-3 demonstrates the enterprise parameters that can be modified to determine the case sensitivity when dialing a URI.

Figure 4-3 URI Lookup Policy Case-Sensitivity Options

CUCM supports the following formats in the domain or host portion of a directory URI (the portion after the @ symbol):

The host portion supports IP addresses or FQDNs.

Accepted characters are a–z, A–Z, 0–9, hyphens, and periods.

The host portion cannot start or end with a hyphen.

The host portion cannot have two periods in a row. The host portion has a minimum of two characters. The host portion is not case sensitive.

URI Endpoint Addressing Overview

Each phone that registers with CUCM is associated with all of its DNs. If an IP phone has a phone button template containing multiple lines, all lines are associated with that device. CUCM can contain virtual DNs that are not tied to any specific phone. However, they are not associated with any phones or video endpoints. Once the IP phone has associated DNs, the URI aliases can be configured. Directory URIs are associated with IP phones and video endpoints in the

following three primary ways:

Manually configured at the End User Configuration page: In CUCM Administration, you can associate or configure a single directory URI at the end-user level. In CUCM Administration, if you browse to User Management > End User and drill into an end-user account, you can associate only a single URI. To achieve this, the end user must be associated with a device, and the primary extension of the device must be selected. As a result, the configured directory URI is associated with the primary extension.

Synchronized via LDAP: When a user is provisioned via Lightweight Directory Access Protocol (LDAP), one directory URI can be imported from LDAP. The most common LDAP synchronization is Microsoft Active Directory. The directory URI field in the CUCM end-user configuration can be populated with either the Microsoft Active Directory

msRTCSIP-primaryuseraddress field or the mail field during LDAP synchronization. It is important to remember that the Active Directory administrator must configure one of these fields with a valid directory URI. Once the LDAP synchronization has been enabled on CUCM, the directory URI field is grayed out and noneditable on the end-user account. Like with manually configured directory URIs, the imported end user must be associated with a device, and the primary extension of the device must be selected. The directory URI can be associated with the

corresponding DN only when the primary extension of the end user is set. When you synchronize with an LDAP directory, CUCM automatically assigns the directory URI value that you choose from the LDAP directory as the primary directory URI for that end user. Even if you have already configured a directory URI as the primary directory URI for that end user’s primary extension, the LDAP value overrides the value that is configured in CUCM Administration.

Manually associated with a DN: At the Directory Number Configuration page, up to five directory URIs can be associated with the DN. One directory URI per DN functions as the primary directory URI. A directory URI that is configured on an end-user page always becomes the primary directory URI of the primary extension of the end user. If no end-user-based

directory URI exists, you can select which of the directory URIs that are configured at the Directory Number Configuration page should be the primary directory URI. By default, the first directory URI that is configured at the Directory Number Configuration page is the primary URI.

The primary URI is used as the calling URI on outbound calls.

Bulk administration: In CUCM, it is possible to bulk administer and update the directory URIs at both the end-user and DN levels. One consideration when performing bulk

administration for directory URIs deals with the encoding of double quotes. Within CUCM

Administration, you can enter directory URIs with embedded double quotes or commas. When you use bulk administration to import a comma-separated values (CSV) file that contains directory URIs with embedded double quotes and commas, you must perform special encoding.

When you use the Bulk Administration Tool (BAT) to import a CSV file that contains directory URIs with embedded double quotes and commas, you must enclose the entire directory URI in double quotes. To further complicate matters, each embedded double quote in the URI must be escaped with a double quote. For example, if you want to use BAT to insert the directory URI Jared, “Jerry”, [email protected], the directory URI must be entered into the BAT CSV file as “Jared,” “Jerry,” “[email protected]”.

URI Partitions and Calling Search Spaces

Configuring a directory URI is similar to that of a regular DN. Once you enter the pattern, you have an option of assigning different partitions. The analogy that many engineers learn about calling search spaces (CSSs) and partitions is that of a lock and key. A partition is a lock that hides numbers, patterns, or URIs. A CSS is the key that grants endpoints the ability to dial the URI. Call routing decisions are enforced in the same manner as a regular DN.

When a directory URI is provisioned via a local end user or an LDAP end user, a default

partition is applied to the URI. The default partition is created during the CUCM installation and is named directory URI. This partition cannot be deleted, but it can be renamed. In addition to renaming the directory URI partition, CUCM allows you to define an alias partition for the directory URI partition. By setting the enterprise parameter Directory URI Alias Partition to an existing partition that all CSSs have access to, the selected alias partition automatically has access to the directory URI partition and its associated DNs. The directory URI alias partition can be found under End User Parameters in the Enterprise Parameters on a CUCM server, as shown in Figure 4-4.

Figure 4-4 The Directory URI Alias Partition Enterprise Parameter in CUCM

To allow calls to end user-based directory URIs, a CSS that includes either the directory URI partition or the directory URI alias partition must be applied to the calling device. The calling device can be any number of sources in CUCM such as gateways, trunks, phones, phone lines, and so on.

Note

This concept differs from the implementation of Presence-enabled call lists. In Presence-enabled call lists, a DN has only one partition, which is used for call routing requests and for requests to watch the Presence status. The CCS that is used for Presence-enabled call lists is configured separately from the CSS for call routing. In addition to the standard CSS, which is used for call routing, there is a subscribe CSS that is configured at the watching phone, which is used to watch the presence status of a DN.

The call routing logic for directory URIs is also identical to the logic for DNs. The best or closest matching pattern is used. If there are multiple equally qualified matching patterns, the order of partitions in the calling device’s CSS is used as a tie-breaker (with priority given to partitions that are listed first). One other item of interest is there is no concept of URI manipulation inside CUCM. With traditional DNs, an administrator could invoke a translation pattern, transformation pattern, or various digit manipulations at the call routing level. With directory URIs, there is no concept of a translation pattern.

URI Call Sources Overview

In CUCM, there can be several different sources of URI calls. These sources can be IP phones, Jabber, video endpoints, SIP trunks, CUBE, and VCS, just to name a few. If you take a look at the entire Cisco IP phone portfolio, there are some model IP phones that do not support SIP URI dialing natively, such as IP Communicator, and Generation 1 7900 series such as 7940 and 7960.

As a possible workaround for these endpoints, calls to directory URIs can be initiated from any Cisco IP phone by using a speed-dial button that is configured with a destination in URI format.

In addition to using speed dials, many IP phone models allow you to enter URIs manually. As mentioned previously, it is a best practice to check the release notes and features guides to see whether the IP phone or video endpoint model supports URI dialing. Cisco Jabber clients and modern IP phones such as Cisco Unified IP Phones 8961, 9951, and 9971 each support URIs and URI dialing.

You can also place calls to call list entries in URI format at supported phones, including Cisco Unified IP Phones 7942, 7963, 7945, 7965, and 7975, and all Cisco Unified IP Phone 6900, 8900, and 9900 series. When a call list entry is used to place an outbound call and the list entry is in URI format, the call is placed to the corresponding directory URI. An example of a call list entry is redialing a missed call using a URI. A user could check his missed call log and one-touch redial a missed call via URI format.

CUCM also routes calls to directory URIs when the calls have been received or placed through a SIP trunk. In the latest XE IOS releases, CUBE supports both traditional dial peers and now

URI-based dial peers. With emerging industry trends, many ITSPs and telco providers are routing calls via SIP and URIs. CUBE allows you to configure URI-based destinations inside dial peers.

With proper planning, it is possible to enable users to dial without entering the domain or

hostname in a URI. This can be particularly convenient with long domain names. When a dialed URI does not include the @ symbol followed by a host portion (that is, only the user portion is dialed), the call fails unless you have configured the enterprise parameter organization top-level domain (OTLD). The OTLD is a setting located in the Enterprise Parameters on the CUCM Administration web page. By default, the OTLD is unset. If the OTLD is set, the @ symbol followed by the configured OTLD is appended to the dialed URI. Setting the OTLD allows users to place calls to URIs by entering only the user portion. One additional setting is the Cluster Fully Qualified Domain Name (CFQDN). These settings are illustrated in Figure 4-5. The CFQDN is directly involved with routing of numeric URIs, as discussed later in this chapter.

Figure 4-5 OTLD and CFQDN Enterprise Parameters Configuration Settings

The OTLD and the CFQDN are important concepts inside Cisco UC. These two settings are not only used for URI and blended addressing, but play key roles in Global Dial Plan Replication

The OTLD and the CFQDN are important concepts inside Cisco UC. These two settings are not only used for URI and blended addressing, but play key roles in Global Dial Plan Replication