06-29-2015 04:40 AM - edited 03-12-2019 10:16 AM
SIP URI
A SIP-URI is the SIP addressing scheme that communicates who to call via SIP. In other words, a SIP URI is a user’s SIP phone number. The SIP URI resembles an e-mail address and is written in the following format:
SIP-URI = sip:x@y:Port where x=Username and y=host (domain or IP)
Note: If you do not specify a port, the default sip port will be assumed (5060). This is shown in the first two examples below. If you have changed the default sip port to something else then you need to specify it in the SIP-URI (third example below).
Examples:
sip:ronak.agarwal@212.123.1.213
sip:support@cisco.com
sip:1234567@cisco.com
Using FQDN or URI to dial an extension.
Supported on limited SIP and SCCP devices.
Directory URI format
Directory URIs are alphanumeric strings consisting of a user and a host address separated by the @ symbol. Cisco Unified Communications Manager supports the following formats for directory URIs:
user@domain (for example, joe@cisco.com)
user@ip_address (for example, joe@10.10.10.1)
Cisco Unified Communications Manager supports 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, !, $, %, &, *, _, +, ~, -, =, \, ?, \, ‘, ,, ., /.
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]. For some accepted characters, Unified CM automatically applies percent encoding. See below for more information on percent encoding.
The user portion is case-sensitive or case-insensitive depending on the value of the URI Lookup Policy enterprise parameter. The default value is case-sensitive.
Cisco Unified Communications Manager supports the following formats in the host portion of a directory URI (the portion after the @ symbol):
Supports IPv4 addresses or fully qualified domain names.
Accepted characters are a-z, A-Z ,0-9, hyphens, and dots.
The host portion cannot start or end with a hyphen.
The host portion cannot have two dots in a row.
Minimum of two characters.
The host portion is not case sensitive.
Due to database restrictions, the Directory URI field has a maximum length of 254 characters.
INTRA-Cluster URI (SIP URI Calling within the cluster):
2. Configure end users:
3. Now, associate the user to the IP phone.
5. Go to the line and you will see the directory URI listed there. Assign the CSS to the phone with the URI partition.
6. You can add upto 5 more URI’s
7. Create a SIP profile and put a check mark beside “Use fully qualified name”
Now, you are ready to do Intra cluster sip uri dialing.
INTER-Cluster URI (URI Dialing across cluster):
To enable intercluster routing of directory URIs, Unified CM can be provisioned to exchange directory URI catalogs with other clusters through the Intercluster Lookup Service (ILS). Each cluster configured to exchange directory URI catalogs with other clusters advertises all locally configured directory URIs in a single directory URI catalog together with a location attribute, the SIP route string. This location attribute in multi-cluster environments is used to direct calls for directory URIs to the correct cluster when the host portion of the directory URI cannot be used to deterministically route the SIP request. This, for example, is the case when a flat URI scheme such as <user>@example.com is use. The host portion "example.com" does not uniquely identify the remote Unified CM cluster that hosts a given URI.
Basically, every cluster would have a catalogue(table) of Directory URI’s. Using ILS each and every cluster would share this catalogue with a local attribute i.e SIP ROUTE STRING.
a. Routing of SIP requests:
The first step is to check the left hand side (user portion) of the URI is a number or URI.
Eg. Ronak@cisco.com LHS==Ronak
b. Numeric URI Versus Directory URI
If the SIP request carries a user=phone tag, the SIP URI will always be interpreted as a numeric SIP URI.
If no user=phone is present, the decision is based on the dial string interpretation setting in the calling device's (endpoint or trunk) SIP profile.
c. Routing Directory URIs
1) Unified CM searches for a full match of the SIP URI against all directory URIs configured in the partitions addressed by the calling device's calling search space. If a match is found, the call is extended to the directory number associated with the matched local directory URI.
2) If no match found, Unified CM tries to locate the SIP URI in imported directory URI catalogs or directory URI catalogs learned from remote systems through the Intercluster Lookup Service (ILS), again by searching for a full match. In case of a match, the SIP request is routed by matching the SIP route string associated with the found directory URI against configured SIP route patterns.
3) In case the SIP URI does not match a local directory URI and also does not match any directory URI in any directory URI catalog, Unified CM then routes the SIP request based only on matching the right-hand side of the SIP URI against configured SIP route patterns. This routing of last resort can be used to create a default route for all SIP URIs not known locally or on any other call control connected through ILS.
Call routing eg explained:
d. How does the above routing works?
Routing Numeric URIs (pre 8.x)
2. The next step is to check whether the right-hand side of the SIP URI matches the organization’s top-level domain configured in Unified CM enterprise parameters. If this is the case, again Unified CM will try to route the call using the calling device's calling search space. But if no match can be found, then routing will fall back to route the call by matching the right-hand side of the SIP URI against the configured SIP route patterns.
3. Assuming a Unified CM cluster with cluster members
IP addresses 192.168.10.10; 192.168.10.11; 192.168.20.10; and 192.168.20.11;
cluster fully qualified domain name configured as ucm1.cisco.com;
organization top-level domain configured as cisco.com, then all of the following SIP URIs would be routed to local directory number 1234:
Assuming that no local directory number 1234 exists, the first five calls would fail immediately while Unified CM would try to route the sixth call by matching cisco.com against the configured SIP route patterns.
Configuration of Intercluster URI:
2. Configure the ILS Configuration under Advanced Feature.
Configure a HUB cluster:
Now, configure the SIP route string:
OR
2. We can also goto Call routing à Intercluster Directory URI and configure it.
Once all this is configured, now configure a SIP Trunk between the 2 clusters.
Assign the appropriate SIP Profile.
Enter the IP of the other cluster.
Save the trunk.
Assign a IPv4 pattern and created SIP trunk.
Configure a spoke cluster:
Now, configure the Sip route string:
NOTE: In order for the clusters to find each other, ILS and URI should be configured on both the clusters. This can be verified using the command: utils ils showpeerinfo
Once all this is configured, now configure a SIP Trunk between the 2 clusters.
Assign the appropriate SIP Profile.
Enter the IP of the other cluster.
Save the trunk.
Assign a IPV4 pattern and created SIP trunk
Important Notes:
If calling from Hub cluster to Spoke, assign the correct css in the spoke cluster’s trunk. This CSS should contain the partition of the directory URI.
If it’s the other way round, then trunk in the Hub cluster should contain the CSS that has the partition of directory URI.
Note: In CUCM 9.1.1, you will have to create a directory URI partition, however, in CUCM 9.1.2, directory URI partition is predefined by “Directory URI” and you cannot delete it.
ILS Troubleshooting tips
To troubleshoot connection issues within the local cluster, use the utils ils find xnode CLI command to determine which server within the cluster is the xnode, the node responsible for communicating ILS updates with remote clusters. After you determine which cluster node is the xnode, you can open RTMT and run alarms and diagnostic traces on that cluster node.
In addition, connection issues may arise if authentication is improperly configured between clusters. Check authentication in the following manner:
If you are using TLS, make sure that all clusters in the network are using TLS and that Tomcat certificates have been exchanged for all the servers that need to communicate.
If you are using TCP password authentication, make sure that all ILS clusters are using TCP password authentication and that the same TCP password is assigned across the network.
2. Directory URIs are not being replicated across the ILS network
This error can occur for a variety of reasons. Check the following:
Verify that all clusters in the network are configured to exchange directory URI catalogs. If a hub cluster is not configured to exchange directory URI catalogs, none of that hub’s spoke clusters will be able to exchange directory URI catalogs.
Allow enough time for end-to-end replication based on synchronization intervals (set on the ILS Configuration page) that are configured for all the clusters involved in the path. All clusters in an ILS network are a maximum of three hops from every other cluster in the network.
Use the utils ils showpeerinfo CLI command to monitor replication progress by looking at the USN values for the remote clusters.
Increase speed of URI replication by changing the ILS Sync Throttle Service Parameter. Note that a low setting can affect system performance.
Verify that all clusters in the ILS network have unique cluster IDs and that none of the clusters are configured with Stand Alone Cluster as its cluster ID. You can check Cluster IDs in Cisco Unified CM Administration under System > Enterprise Parameters.
3. Directory URI Replication is configured, but Unified CM still cannot place a call to a directory URI in a remote ILS cluster
This condition can occur if ILS and URI replication are enabled on all clusters in the network, but SIP route patterns that route to the route strings for the remote clusters have not been configured. Do the following:
In the ILS Clusters and Directory URI Catalogs view in the ILS Configuration window, check the route string for the remote cluster.
In the SIP Route Pattern configuration window, make sure that you have route patterns that map to the route strings for your remote clusters.
Use the utils ils findroute CLI command to check for duplicate route strings.
Refer to http://www.ietf.org/rfc/rfc2396.txt for more details.
Regards,
Ronak Agarwal
Nice DOC.[+5]
regds,
aman
nice doc.. do you have docs for external URI dailing (not local domain) ?
very well done doc!
I've a question regarding inter-cluster URI dialling. I have an ILS network setup between 2 leaf nodes and a SME. I'm using OTLD/FQDN example.com/cucm.example.com.
The issue is that calls between phones registered to different leafs do not display as calling name:
user@example.com instead just user.
I've flagged the Use FQDN for SIP requests under the SIP profile assigned to each of the phones.
Any suggestions?
Excellent document Ronak !
Regards
Lavanya
Hi,
Did you check the below in the SIP Trunk outbound call section.
calling and connected party info format --- Deliver URI and DN..
Regards,
Raaj
Great doc, but quick question ... Which version did you use to create this?
This is only 8 months old, however your section "configure the SIP route string" does not exist in CUCM 10.5 version.
Hi
Does Directory and organization top level domain should be same ?
What i mean if the user have directory uri xxx@cisco.com on the line does it need be equal organization top level domain cisco.com
For example: customer organization top level domain is: video.cisco.com but they have cisco.com directory uri on the line .
I can able to dial user username@video.cisco.com but can not dial using with username@cisco.com
Thanks
I get this error when I make a call at the SRST gateway:
Received:
INVITE sip:x-cisco-serviceuri-offhook
In Routing Numeric URIs topic
the documents say that for outbound calls from CUCM line's registered through SIP TRUNK,
if the "Use Fully Qualified Domain Name in SIP Requests" is checked under the SIP PROFILE, the URI domain of the caller is match to the Organization Top Level Domain but what is happen if the Organization Top-Level Domain field is empty?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: