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):
- Configure a SIP URI partition in the Enterprise parameters.
2. Configure end users:
- User1 and User2 and assign the Directory URI
- Associate the Primary extension to the user and associate the device.
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:
- Alice calls carol@cisco.com.
- Unified CM searches for the local URI, and it’s not found.
- ILS lookup leads to routestring fra.route
- Call routes to the other cluster over SIP Route pattern.
- Carol@cisco.com found in the other cluster and call completes.
d. How does the above routing works?
- All local directory URIs of this Unified CM cluster are advertised under the SIP routestring fra.route.
- As part of this information exchange over ILS, the Unified CM cluster at the top populated its local directory URI catalog with the association of carol@cisco.com to the SIP routestring fra.route.
- If someone then places a call from the phone registered in the top cluster to directory URI carol@cisco.com, the local lookup of directory URI carol@cisco.com will fail because carol@cisco.com is not a local directory URI.
- The next step in the routing process is to search for carol@cisco.com in the table of directory URIs learned through ILS.
- This search will find the information learned from the bottom cluster, and the originating cluster at the top then takes the learned SIP routestring fra.route and tries to find a route by matching this SIP routestring fra.route against the configured SIP route patterns.
- A SIP route pattern fra.route is configured and points to a route list that ultimately leads to the SIP trunk pointing to the target Unified CM cluster.
- On the destination cluster, the same routing logic then tries to match carol@cisco.com against all local directory URIs on the destination cluster, which leads to a full match and the target device rings.
- In the above example, the SIP route strings chosen basically identify the individual call controls (fra.route, nyc.route), and the SIP route pattern grid used to route directory URI SIP requests based on learned SIP route strings uses explicit patterns (fra.route, nyc.route) to create the desired reachability.
Routing Numeric URIs (pre 8.x)
- First step is to check the Right hand side of the URI. If it contains the IP address of any server that is a member of the Unified CM cluster or matches the cluster fully qualified domain name configured in Unified CM enterprise parameters, then Left hand side of the URI would be checked and call would be routed locally using the CSS of the calling device.
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:
- 1234@192.168.10.10
- 1234@192.168.10.11
- 1234@192.168.20.11
- 1234@192.168.20.10
- 1234@ucm1.cisco.com
- 1234@cisco.com
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:
- Assign the Cluster ID in enterprise parameters to the cluster. It should not be a standlone.
2. Configure the ILS Configuration under Advanced Feature.
Configure a HUB cluster:
- Give it the role of HUB CLUSTER.
- Set the sync time
- Use password and it should be a minimum of 6 alphanumeric digits.
- Enter the concerned node.
- Once you click on save, then a window would pop-up asking, if you want to connect to any other server acting as a HUB cluster. You can leave it blank if not using it.
- Save the config.
Now, configure the SIP route string:
- Go to Advanced feature à ILS Conf
- Go to Related links and select Intercluster Directory URI Configuration.
- Put a check mark and give it a name nyc.route
OR
2. We can also goto Call routing à Intercluster Directory URI and configure it.
- SIP Trunk configuration:
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.
- SIP route pattern configuration:
Assign a IPv4 pattern and created SIP trunk.
Configure a spoke cluster:
- Give it the role of Spoke.
- Set the sync time
- Use password and it should be a minimum of 6 alphanumeric digits.
- Enter the concerned node.
- Click save and it would ask you to enter the IP of the Hub cluster.
- Save the configuration and it would restart the ILS service on all the nodes.
Now, configure the Sip route string:
- Go to Advanced feature à ILS Conf
- Go to Related links and select Intercluster Directory URI Configuration.
- Put a check mark and give it a name fra.route
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
- SIP Trunk configuration:
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.
- SIP route pattern configuration:
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
- Local cluster cannot connect to the ILS network
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
