Configuring Directory URI Dialing for Cisco Jabber

Step-1 Associate URIs to DNs. This can be done automatically or manual

Note: You can create up to 5 directory URIs per user and nominate a primary one.

a. Automatically Populate Directory Numbers with URIs - Manual User Creation
When create end users in CUCM, you can associate devices to them as well as primary extensions. Also, you can populate directory URI field for end users. Configuring directory URI for end user with primary extension associated will populate the directory URI field for this DN automatically

The directory URI in the DN will be automatically assigned to 'Directory URI' partition. This partition is automatically created by CUCM and can't be modified or deleted. 'Directory URI' partition created by CUCM and assigned automatically to directory URIs is an alias and the actual partition mapped to it is controlled by the enterprise service parameter 'Directory URI Alias Partition'

The calling party CSS should include 'Directory URI Alias Partition' to be able to dial directory URIs

b. Automatically Populate Directory Numbers with URIs - LDAP Integration 
In this case, end users will be synchronized from LDAP server with 'directory URI' field pre-filled with LDAP attribute. Once you assign primary extensions to synchronized end users, 'directory URI' for DNs will be automatically populated.

Directory URI field can be filled with 'mail' LDAP attribute or 'msRTCSIP-PrimaryUserAddress' LDAP attribute
 

c. Manually create directory URIs in DNs 
In this case, as a part of creating DNs, you can assign directory URI to the DN along with respective partition. Calling parties should contain 'directory URI' PT in their CSSes.

Step-2 Add a valid Fully Qualified Domain Name (FQDN) into the enterprise service parameter “Clusterwide Domain Configuration”

Step-3 Enable FQDN in SIP Requests for Contact Resolution - Device > Device Settings > SIP Profile > Use Fully Qualified Domain Name in SIP Requests 

Step-4 Enable Directory URI in Jabber Client XML file - true

Globalized Dialplan Implementation

Note: For calling and called party transformation patterns CSS, if applied at DP, make sure that phones and gateway for specific site are in different DPs

Localized Calls Ingress on Phones - Once the user enters the dialed number

1. In case the called number is in globalized format (typically +E164), CUCM should accept it and start matching process
2. In case the called number isn't in globalized format, TPs should be used to globalize it (typically +E164). TPs must configured to accept all dialing habits from local users
3. In case the calling number is in globalized format (typically +E164), CUCM should accept it
4. In case the calling number isn't in globalized format, under Phone Configuration Window > Caller ID For Calls From This Phone > Calling Party Transformation CSS should be used to match Calling Party Transformation Pattern and globalize the calling number. You can apply this CSS at DP level instead of per phone

Note: Don't use TPs to globalize Calling Party Information because TPs aren't compatible with URI dialing

Localized Calls Ingress on Gateways - Once the gateway receives call from PSTN

1. The called number can be globalized using one of the following methods:
1. Using Call Routing Information - Inbound Calls section under the trunk or gateway. You can configure the number of significant digits and add prefix to these digits. For example, if the received called number is 5051234, you can configure the significant digits as 4 (1234) and prefix +1408561 which will convert the number to +14085611234
2. Using TPs to match the received called number and globalize it to standard format (typically +E164) used in CUCM. The Calling Search Space configured under Call Routing Information - Inbound Calls should have access to the TPs.
3. On H323/MGCP gateways, use Incoming Called Party Settings to globalize the received called number based on TON attribute. This configuration can be applied on DP as well instead of per gateway. Alternatively, under the same section, you can use CSSes to use Called Party Transformation Patterns. For this, you need to keep other fields as Default
2. The calling party information should be globalized using Incoming Calling Party Settings either based on TON attribute or CSSes combined with Calling Party Transformation Patterns. For example, a calling number received with TON as 'National' requires to prefix '+' sign, country code and area code. While a number received with TON as 'International' requires to prefix '+' sign only.

Localized Calls Egress - Once the call is delivered to phone or gateway with globalized calling and called numbers

1. For calls delivered to phone after globalized routing, use Remote Number > Calling Party Transformation CSS to localize the calling number. The localized number will be presented on phone display but the number stored in Missed Calls or Received Calls directory will remain in globalized format for Type-B phones. For Type-A phones, the localization will impact the directory as well.
1. If the globalized calling number represents a local user, it should be localized to 4-digits extension
2. If the globalized calling number represents a subscriber number, it should be localized to subscriber format
3. If the globalized calling number represents a international/national number, it should be localized to international format
2. For calls delivered to gateway after globalized routing, use Calling Party Transformation CSS to localize the calling number and TON to suitable format. For example, for calls existing San Francisco gateway, any globalized calling number with +1415! should be localized to strip '+', country code, area code and change TON to subscriber. Other calls existing San Francisco gateway with globalized calling number with +1! should be localized to strip '+', country code, and change TON to national.
3. For calls delivered to gateway after globalized routing, use Called Party Transformation CSS to localize the called number and TON to format suites the telco. For SIP Trunks, the TON can't be set and have to be 'Unknown'

Calling Search Spaces in Globalized Dialplan

The calling search spaces configured for each site should generally allow for:

• Localized intra-site dialing habits of the site - This will hit TPs
• Localized off-net dialing habits of the users at the site - This will hit TPs
• Applicable local telephony services such as emergency calls, directory, and operator services
• The globalized form of on-net and off-net numbers - This will hit RPs/DNs directly

Note: In case of overlap between globalized RP patterns and DNs/TPs, use Urgent priority to overcome the problem