Editor’s Note: TS Newsletter readers get a 35% discount on Akhil Behl's book CCIE Collaboration Quick Reference. See discount code at the end of this article.
Cisco Collaboration solutions offer much more than just traditional ways to communicate within and outside of an enterprise network. Complementing the next generation communication solutions such as SIP gateways, SIP endpoints, Jabber, WebEx etc., Cisco Unified Communications Manager (CUCM) has evolved to a degree that it can work and integrate with multiple platforms and can serve multitude endpoints. This article highlights features and benefits of the recent inclusion – SIP Uniform Resource Identifier (URI) based dialing as well as support for Intercluster Lookup Service (ILS) Networking.
SIP URI Dialing
In context of Cisco Collaboration, SIP URI can be best compared to an email address such as email@example.com. The URI format is usually general form: sip:user:password@host:port;uri-parameters?headers. This format has been used by SIP dominant networks for years and is now gaining universal popularity because of its globally routable (DNS-based) nature/capability. A SIP URI can be automatically imported from LDAP (provided the cluster is integrated with an LDAP server) such as a mail or the msRTCSIP-primaryuseraddress attribute.
Following are salient features of SIP URI:
- In a SIP URI a user name is optional however, CUCM does not support URIs without a user name
- URI parameters and headers are optional
- The user name is case sensitive however host is case insensitive (RFC 3261). This parameter is configurable starting CUCM 9.1 (under Enterprise Parameters – URI lookup policy)
A URI can be dialed with or without the domain name, because calling “abc”, adds “cisco.com” automatically from domain name configured in the Organizational Top Level Domain service parameter in CUCM as shown in figure 1-1.
Figure 1-1: CUCM Clusterwide Domain Configuration
SIP URIs help securely extend your entire Collaboration infrastructure’s communications because almost all current SIP phone loads, all Telepresence endpoints, and Jabber 9.6+, support URI dialing. To configure a SIP URI, browse to Device > Phone and select a phone and in-turn a line for which SIP URI is to be configured as shown in figure 1-2.
Figure 1-2: SIP URI Configuration
While SIP URI is a native dialing method in SIP-based video environment and allows better integration with other call controls where URI dialing is native dialing habit (e.g. VCS); it does have certain limitations. For example, URIs cannot be used for PSTN calls, therefore they need to be mapped to E.164. URIs also have limited endpoint support (older phones do not support SIP URI).
While dialing within the same domain and cluster is not an issue; however, dialing with a flat hierarchy in a domain and multiple clusters does pose a problem. In other words, supporting URI addressing between multiple clusters can be an issue and an administrative overhead. This issue is taken care of via Inter-Cluster Lookup Service (ILS). The next section dives into specifics of ILS Networking.
Inter-Cluster Look-up Service (ILS) is a cluster-wide service in CUCM that when configured on and between CUCM clusters, synchronizes information throughout the “ILS Network”. Before getting to the nuts and bolts of ILS, let’s understand what value it adds to SIP URI dialing between clusters.
- URI dialing wouldn’t work well in a multi-cluster environment because of mass configuration requirements, routing loops, call setup delays, and so on.
- It will be necessary to duplicate patterns on each cluster.
- Manual configuration of Jabber clients to a specific cluster will be a mandate as the Jabber client needs to get directed to the cluster where it will be registered and get its configuration.
- Support for URI addressing and Home Cluster Discovery becomes much easier.
- Administrative overhead in a multi-cluster environment is greatly reduced.
- It allows for adoption of powerful dial plan concepts such as TEHO.
The ILS Network Establishment (which is essentially peering relationships) enables URI and Global Dial Plan replication, for example alternate number advertising.
In an ILS network, ILS Node Types can be:
CUCM clusters participating in ILS network form a hub and spoke topology; each cluster is either a hub or spoke. Hubs must be fully meshed with spokes. Figure 1-3 shows various ILS topologies.
Figure 1-3: ILS Network Topologies
Using ILS, each node replicates its URIs to its neighbor’s (or Hubs) and also announces “SIP route string” together with the URIs. CUCM clusters establish ILS Exchange and then URI information is flooded. Then, each cluster creates a table with URIs and associated SIP route string(s). Finally, SIP route strings are routed by SIP route patterns.
Note: Before configuring ILS it is important to Set Organization Top Level Domain (OTLD) to match a single corporate domain name and the Cluster Fully Qualified Domain Name (CFQDN) to match the host names of respective clusters/nodes. For example, if cisco.com is the OTLD then the EU cluster can be named as eu.cisco.com and the US cluster can be named as us.cisco.com. This arrangement is illustrated in figure 1-1.
Considering that not all endpoints support or need to support SIP URI, the notion of blended addressing comes into perspective, where traditional numeric Directory Numbers (DNs) and (alphanumeric) SIP URIs coexist on endpoint DN. In such case, CUCM will relay an alphanumeric hostname of a caller to the called endpoint as a part of the SIP header information. This enables the called endpoint to return the call using the received or missed call list. In mixed environments where numeric and SIP URIs exist, it’s important to always have FQDNs in SIP requests for all calls. For endpoints registered with CUCM the FQDN in SIP requests will be set to the OTLD configured in the enterprise parameters. The next section briefly discusses blended addressing concept in CUCM.
In CUCM SIP, URIs are assigned to DNs where DNs are the “primary” identity of the devices. When an environment is configured with both a DN and an SIP URI, you may wonder whether it is the DN or the SIP URI that is the “correct” identity to be presented during calls. Well, the answer is – It mainly depends on the devices involved in the call and if they prefer one over the other. For example, video endpoints use SIP URIs over DNs.
“Blended Identity” is the combination of a DN and an SIP URI. CUCM can build missing pieces by looking at the primary URI configured on a DN if the calling party dialed a DN and searched for a DN that has the primary URI when the calling party called using a URI. It is the configuration of trunks on CUCM that defines whether the calling and called party information contains a DN, a URI, or blended addressing. This is shown in figure 1-4.
Figure 1-4: SIP Trunk Configuration to Deliver DN and URI
Cisco Collaboration solutions offer a rich feature that is user friendly and allows dialing by URI (username, email address etc.) instead of remembering the phone number(s). This allows enterprise to scale their communication network and administrators to effectively manage the solution. SIP URI dialing has been used for years and is now available at the fingertips of Cisco Collaboration users. In addition, blended addressing helps keep both traditional directory number-based and new name-based dialing together. On the other hand, ILS networking solves the issue of overlapping URI addressing schemes in a multi-cluster environment. Together, SIP URI, ILS Networking, and blended addressing give a powerful, scalable, robust, and highly interoperable collaboration network at disposal of administrators and users alike.
Akhil Behl is a Solutions Architect with Cisco Services, focusing on Cisco Collaboration and Security Architectures. He leads Collaboration and Security projects and service delivery worldwide for Cisco Advanced Services and the Collaborative Professional Services (CPS) portfolio. He's played major role in service conception and creation for various services within Cisco Advanced Services. He has Pre-Sales to Sales to Professional Services to Delivery to Post Sales experience with expertise in Consulting, Advisory, and Guidance services. He has extensive experience in Borderless, Collaboration and Data Center portfolio. Prior to his current role, he spent ten years working in various roles at Linksys as a Technical Support Lead, as an Escalation Engineer at Cisco Technical Assistance Center (TAC), and as a Network Consulting Engineer in Cisco Advanced Services.
Akhil has a bachelor of technology degree in electronics and telecommunications from IP University and a master’s degree in business administration from Symbiosis Institute. He is dual Cisco Certified Internetwork Expert CCIE # 19564 in Voice and Security. He also holds many other industry certifications, such as PMP, ITIL, VCP, CCNA, CCSP, CCVP, ISO/IEC 27002, TOGAF and CEH.
Over the course of his career, he has presented and contributed at various industry forums such as Interop, Enterprise Connect, Cloud Connect, Cloud Summit, Cisco Networkers, and Cisco SecCon. He also has several research papers published in various national and international journals including IEEE.
By Akhil Behl
Series: Quick Reference
Published: May 20, 2014
ISBN-10: 0-13-384596-6ISBN-13: 978-0-13-384596-9
Published by Cisco Press.
DISCOUNT: 35% off ciscopress.com for Cisco Technical Newsletter customers; use code CISCOTECH at checkout.
This Chalk Talk is featured in the July 2014 Cisco TS Newsletter. Subscribe now and get Tech Insights, Services Updates, and TAC-inspired Technical documents delivered to your inbox each month!