Implementing Intercluster Lookup Service

Transcription

1 Appendix 11 Implementing Intercluster Lookup Service Overview When using the Session Initiation Protocol (SIP), it is possible to use the Uniform Resource Identifier (URI) format for addressing an end user. Intercluster URI calls are routed based on the host part of a URI. Therefore, each cluster must use a different URI host part. The Intercluster Lookup Service (ILS), a feature that was introduced in Cisco Unified Communications Manager version 9, provides a mechanism that allows the same host part to be used in URIs across clusters. This lesson explains how ILS works, describes its main components, and how to implement ILS. Upon completing this lesson, you will be able to describe the purpose of ILS, its functions, and how to implement it. This ability includes being able to meet these objectives: Describe the purpose of ILS and the services it provides Describe the components of ILS networking and their functions Describe how URI syncing works and how it interacts with URI routing Describe what needs to be considered when implementing ILS Implement and monitor ILS operation

2 ILS Overview This topic provides an overview of ILS, a feature that was introduced in Cisco Unified Communications Manager version 9. Other clusters are reached based on SIP route patterns that match the host portion of the called URI. URI routing requires unique host portions per cluster amer.cisco.com emea.cisco.com [email protected] [email protected] [email protected] 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v Before Cisco Unified Communications Manager version 9, URI routing was based on the host part (the domain) of a URI. A SIP route pattern was configured for each domain, and this route pattern referred to a SIP trunk. The SIP trunk then pointed to one or more servers of the remote cluster. In order to route URIs successfully, the host part of URIs must be unique to each cluster. The figure shows an example with three Cisco Unified Communications Manager clusters. Each of them uses a dedicated domain (amer.cisco.com, emea.cisco.com, and apac.cisco.com) for the host part of its local URIs. Each cluster has two SIP route patterns and two SIP trunks that refer to the other two sites. This is a typical implementation of intercluster URI routing Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

3 Flat Domain Scheme Causes Problems with Multicluster URI Routing In some multicluster deployments, customers want to use a single domain for all URIs across all clusters. If URI host portions are not unique across clusters, URI routing does not work: No cluster identification is possible. Calls to remote destinations will fail. [email protected]? [email protected] [email protected] 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v The type of configuration that is shown in the figure causes problems with URI routing because there is no information in the URI that enables a Cisco Unified Communications Manager to find out the location of the endpoint. If the cluster where the target device is registered is not known, Cisco Unified Communications Manager cannot route the call. Consequently, a flat domain scheme or any overlapping of domains across clusters are not supported for URI routing in earlier versions than Cisco Unified Communications Manager version Cisco Systems, Inc. Implementing Intercluster Lookup Service 11-3

4 ILS Solves Multicluster URI Routing Issues with Overlapping Domains With Cisco Unified Communications Manager version 9, ILS can be used to solve URI routing issues when using overlapping domains in the host part of directory URIs. Each cluster is configured with a globally unique route string. Each cluster propagates its local URIs and its local route string to all other clusters. Each cluster learns all remote URIs and a route string that is associated with each URI. Call routing is not based on the URI host portion but on a learned route string. This allows the same URI host portion (domain) to be used at multiple clusters. SIP route patterns: amer.cisco.com emea.cisco.com [email protected] route string: amer.cisco.com ILS URI exchange: [email protected] -> amer.cisco.com [email protected] -> emea.cisco.com route string: emea.cisco.com [email protected] 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v ILS provides a mechanism to propagate individual URIs. In addition to the URI, each cluster adds a tag that uniquely identifies the cluster. This tag is called the route string, and it is configured by the administrator. In most cases, a cluster-specific subdomain of the enterprisewide domain is used. Through the propagation mechanism, all clusters learn all URIs and the associated route string. When a call is placed to a URI and the full URI is found in the ILS routing table, then a SIP route pattern for the associated route string is searched instead of the domain part of the called URI. In summary, ILS decouples the call routing information from the URI that is actually called and thus allows the same URI host part to be used across clusters. ILS is a new Cisco Unified Communications Manager feature service. This service builds on the existing SIP route pattern constructs. Other than Service Advertisement Framework (SAF) and Call Control Discovery (CCD), ILS does not eliminate the need to configure SIP trunks. It only modifies the process of choosing a configured SIP route pattern and the associated SIP trunk. Note Although SAF and CCD provide similar services (dynamic discovery of remote cluster information), there are many differences. For example, SAF and CCD do not support routing of alpha URIs, and ILS does not eliminate the local configuration of call routing information. ILS requires SIP route patterns and SIP trunks to be statically configured. The figure shows a multicluster deployment with two clusters. URIs in both clusters use the same domain for the host part of the URIs. Each cluster has a unique route string 11-4 Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

5 (amer.cisco.com and emea.cisco.com). Each cluster has a SIP route pattern that is configured. This SIP route pattern points to a SIP trunk, which then refers to the other cluster. This part of the configuration is static and is stored in the Cisco Unified Communications Manager configuration database. In addition, ILS is enabled at the two clusters and therefore each cluster advertises its local URIs along with the locally configured route string. In the example, the cluster shown on the left advertises URI [email protected] with route string amer.cisco.com. The cluster shown on the right advertises URI [email protected] with route string emea.cisco.com. After synchronization, each cluster has a URI that is applied to a local phone and a URI that is learned via ILS. When a call is placed to a remote URI, Cisco Unified Communications Manager finds the URI in the ILS URI routing table and looks up the associated route string instead of the host part of the called URI. The route string matches the statically configured SIP route pattern and is then routed out via the associated SIP trunk Cisco Systems, Inc. Implementing Intercluster Lookup Service 11-5

6 Main ILS Components This section lists and describes the main components of ILS. Component ILS Networking URI Syncing Description Joins clusters into a network. Provides discovery of ILS services available on remote clusters. An ILS service that propagates and learns URIs and associated route strings. Propagation: Each cluster advertises all locally configured URIs and the locally configured route string to all other clusters. Learning: Each cluster listens to the advertisements that are sent by other clusters and builds a table of learned URIs and their associated route strings Cisco and/or its affiliates. All rights reserved. COLLAB90 v ILS consists of two main components: ILS networking: ILS networking joins clusters into a network. ILS networking provides a discovery of ILS services that are available on remote clusters. ILS services can utilize the ILS network to propagate service-specific information across clusters. URI syncing: URI syncing is an ILS service that propagates and learns URIs and their associated route strings throughout the members of an ILS network. Each cluster advertises all locally configured URIs and the locally configured route string of the cluster to all other clusters. Each cluster listens to the advertisements that are sent by other clusters and builds a table of learned URIs and their associated route strings. URI syncing is a service that interacts with other clusters and therefore is listed at the Cluster View page in Cisco Unified Communications Manager Administration. Other remote services that are shown on the Cluster View page include Location Bandwidth Manager (LBM), User Data Service (UDS), and services that relate to Cisco Extension Mobility Cross Cluster (EMCC) such as public switched telephone network (PSTN) access, Resource Reservation Protocol (RSVP) agent, and TFTP. When comparing SAF and CCD to ILS, ILS networking provides the functionality of SAF, and URI syncing provides the functionality of CCD Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

7 ILS Networking This topic describes ILS networking topologies. Clusters can be joined together to form an ILS network. Each cluster in an ILS network has a hub or spoke role. Each hub syncs directly with all other hubs (full mesh between hubs) and with its own spokes. A hub can have no spokes, one spoke, or more than one spoke. Each spoke has one hub and syncs directly with only this hub. Hub1, One Spoke Hub3, No Spokes Spoke2 Spoke1 Hub2, Two Spokes Full Mesh of Three Hub Clusters Spoke Cisco and/or its affiliates. All rights reserved. COLLAB90 v Cisco Unified Communications Manager clusters can be joined together to form an ILS network. Each cluster in an ILS network has one of the following roles: hub or spoke. Each hub synchronizes information directly with all other hubs and with its own spokes. A hub can have no spoke, one spoke, or more than one spoke. Each spoke has one hub and synchronizes information with only this hub. In summary, hubs are fully meshed, and spokes form a star topology with their hub. Any combination is possible: a single hub with associated spokes, multiple hubs with no spokes, or a mixed topology, as shown in the figure. By default, each cluster is in standalone mode. This means that the cluster is not part of an ILS network Cisco Systems, Inc. Implementing Intercluster Lookup Service 11-7

8 ILS Synchronization This section describes how ILS synchronization occurs within an ILS network. Synchronization in an ILS network is pull-based. Sync interval is configured at each cluster (default 10 minutes, minimum 1 minute, and maximum 24 hours). Per interval, cluster pulls in information from every other cluster that is directly associated. - Hubs pull information from all other hubs. - Spokes pull information from their hub. Convergence time depends on the synchronization path (number of hops) and configured sync intervals. - Maximum distance in an ILS network is three hops: spoke hub hub spoke. - Maximum convergence time is the total of sync intervals along the synchronization path (by default, 30 minutes). Spoke1 Hub1 Hub2 Spoke1 Pull Hub1 Pull Hub2 Pull Spoke Cisco and/or its affiliates. All rights reserved. COLLAB90 v Synchronization in an ILS network is pull-based. This means that each cluster requests information from its connected clusters. Spokes pull information only from their hub. Hubs pull information from all other hubs. The synchronization interval can be configured independently at each cluster. The default is 10 minutes, and the configurable range is from 1 minute to 1440 minutes (24 hours). Because each cluster can be configured with different synchronization intervals, update times can also be different. The maximum update time is the total of all synchronization intervals along the synchronization path. The maximum synchronization path is determined by the ILS network topology. Because all hubs are fully meshed, the maximum number of hops in every ILS network is three. The figure shows this topology. Spoke1 is connected to Hub1. Hub1 is connected to Hub2, which is connected to Spoke2. When calculating the maximum update time for updates that occur in Spoke2 to be seen at Spoke1, the synchronization intervals of Spoke1, Hub1, and Hub2 are relevant. The synchronization interval of Spoke 2 is not applicable in this case. Note Although the synchronization interval can be configured independently per cluster, it is recommended that you configure the same synchronization interval at all members of an ILS network Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

9 ILS Networking: Operation Within a Cluster This section describes ILS networking operation within a cluster. ILS is a feature service that is activated per server. The recommendation is to activate ILS on all servers of a cluster. One server per cluster is designated as the cluster xnode: - The xnode is automatically selected and cannot be configured. - The xnode manages most of the communication with other clusters. Hub1 Hub3 Spoke2 Spoke1 Spoke3 Hub Cisco and/or its affiliates. All rights reserved. COLLAB90 v ILS is a feature service that can be activated or deactivated on each server within a cluster. It is recommended that you activate ILS on all servers of a cluster that joins an ILS network. One server per cluster is designated as the cluster xnode. The selection of the xnode is performed automatically and cannot be influenced by the administrator. Out of the servers that are running the ILS service, the subscriber server with the lowest node ID is designated as the xnode of the cluster. If the ILS service is only activated on the publisher, then the publisher is designated as the xnode. In a Cisco Unified Communications Manager cluster deployment (that is, when subscribers are present), it is not recommended that you activate the ILS service at the publisher only. The xnode manages most of the communication to other clusters Cisco Systems, Inc. Implementing Intercluster Lookup Service 11-9

10 URI Syncing This topic describes how URI syncing works and how URIs that are learned via ILS are used for URI routing. URI syncing propagates and learns URIs and associated route strings. It can be configured on clusters that are members of an ILS network. It uses ILS network synchronization capabilities. Each cluster builds a complete list of URIs and associated route strings. - The list is stored in memory, not in the configuration database. - The list is used by the URI routing process if no local match is found: Is user portion of URI a DN? No Does URI match an entry in any accessible partition of local URI table? No Does URI match any learned ILS URI? No Does host portion of URI match a SIP route pattern in any accessible partition? No Block call. Yes Yes Yes No Yes Route as a DN. Offer call. Does route string of matched ILS URI match a SIP route pattern in any accessible partition? Yes Route using matching SIP route pattern Cisco and/or its affiliates. All rights reserved. COLLAB90 v URI syncing learns and propagates URIs and the associated route strings. URI syncing can be enabled on clusters that are part of an ILS network. URI syncing utilizes ILS network synchronization capabilities to exchange its data across all participating clusters. URI syncing follows the same syncing topology and syncing intervals as ILS networking. For example, a spoke syncs URIs directly only with its hub and indirectly with the rest of the network via its hub. Although URI syncing is configured cluster by cluster, a deployment in which URI syncing is intended, but is not configured on every cluster in the ILS network, is not recommended because it may easily result in errors. For example, if URI syncing is enabled on a spoke but not on its hub, the spoke will not be able to sync URIs with any other clusters. URI syncing enables each cluster to build a complete list of URIs and associated route strings. These ILS URI routing entries are stored only in the memory of the ILS servers. They are not stored in the cluster configuration database. The figure indicates how the ILS URI routing table is used by the URI routing process: If the user part of a URI is a directory number, then the number is looked up in the numeric call routing table. Note This lookup considers all entries of the numeric call routing table that are accessible to the calling device based on the calling search space (CSS) of the calling device and the partitions that are assigned to the routing table entries. If the user part of a called URI is not a directory number, then the full URI is looked up in the URI routing table, which contains all locally configured URIs (URIs that are applied to phones). If a match is found, then the call is sent to the locally registered device Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

11 Note This lookup is also following the CSS and partition logic. Like directory numbers, locally configured URIs can be assigned a partition. There is no separate CSS for URI routing. The CSS that is used for numeric call routing is also applicable to URI routing. If no match is found, then the full URI is looked up in the ILS URI routing table. Note The lookup in the ILS URI routing table always considers all entries of the ILS URI routing table. ILS URI routing table entries do not have a partition that is assigned, and the CSS and partition logic do not apply to ILS URI routing table lookups. If a match is found in the ILS routing table, then the associated route string is matched against all accessible SIP route patterns. If no matching SIP route pattern is found, then the host part of the originally called URI is looked up against all SIP route patterns. If the full URI was not found in the ILS URI routing table, then the host part of the originally called URI is matched against all SIP route patterns. Note SIP route patterns can be assigned a partition. When a route string or the host part of a called URI is matched against the SIP route patterns, the CSS and partition logic applies: SIP route patterns in partitions that are not included in the CSS of the calling devices are ignored. If a matching SIP route pattern is found, then the call is routed using the matched SIP route pattern. If no matching SIP route pattern is found, then the call fails Cisco Systems, Inc. Implementing Intercluster Lookup Service 11-11

12 URI Import and Export This section describes the option to import and export URIs into Cisco Unified Communications Manager. URIs can be imported from third-party systems, such as VCS and OCS: Each import is stored in a directory URI-imported catalog. The Cisco Unified Communications Manager administrator assigns a route string to each directory URI-imported catalog. URIs and associated route strings of directory URI imported catalogs are treated as if they were learned via ILS URI syncing. URI-imported catalogs are also propagated to other clusters on the next pull. Local URIs can be exported: They can be exported and then imported on third-party systems that support URI import. ILS-learned URIs and imported URIs cannot be exported. To export all URIs of all clusters, export local URIs at each cluster Cisco and/or its affiliates. All rights reserved. COLLAB90 v URIs can be manually imported from third-party systems such as Cisco TelePresence Video Communications Server (VCS) and Microsoft Office Communications Server (OCS) or Microsoft Lync server. Each import is stored in a directory URI-imported catalog. The Cisco Unified Communications Manager administrator assigns one route string to each directory URI-imported catalog. Imported URIs and their associated route strings are treated as if they were learned via ILS URI syncing. They are also propagated to other clusters on the next pull. Imported directory URI catalogs can be updated by uploading a new file. In this case, the changes are propagated at the next pull. Locally configured URIs can be exported in order to be imported on third-party systems that support URI import. ILS-learned URIs and imported URIs are not included in the URI export function. Therefore, to export all URIs of a multicluster deployment, you must export the local URIs at each cluster Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

13 ILS-Based Multicluster URI Routing Process The example in the figure illustrates the URI routing process in an ILS-enabled multicluster deployment. ILS URI syncing is enabled, and URIs are exchanged. When calls the following happens: 1. URI is not found locally using CSS and partitions. 2. Match in ILS table is found; associated route string is emea.cisco.com. 3. SIP route pattern for emea.cisco.com exists and is matched. 4. Call is routed via the associated SIP trunk. ILS URI Syncing: Route String: amer.cisco.com ILS-Learned URIs: -> emea.cisco.com SIP Route Patterns: emea.cisco.com -> amer.cisco.com -> emea.cisco.com Route String: emea.cisco.com ILS-Learned URIs: -> amer.cisco.com SIP Route Patterns: amer.cisco.com 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v The example shows two clusters that are part of an ILS network. URI syncing is enabled, and URIs and route strings have been exchanged. When calls the following URI routing process occurs: Step 1 Step 2 Step 3 The full called URI is looked up in the local URI routing table. The CSS of the calling device is used to determine which partitions of the URI call routing table are considered in the lookup. In the example, the call URI does not exist in the local cluster URI routing table. The full called URI is looked up in the ILS URI routing table. This lookup does not utilize the CSS of the calling device because ILS URIs do not have an assigned partition. When the ILS URI routing table is searched, all patterns are subject to the search. In the example, a match is found. The matched ILS URI entry [email protected] is associated with route string emea.cisco.com. The route string that is associated with the matched ILS URI entry (emea.cisco.com) is matched against all configured SIP route patterns. In the example, a SIP route pattern for emea.cisco.com is found, and the call is routed according to the SIP route pattern. The CSS of the calling device is used to determine which partitions of the SIP route pattern table are considered in the lookup Cisco Systems, Inc. Implementing Intercluster Lookup Service 11-13

14 ILS Considerations This topic describes what you should consider when implementing ILS. Different sync timers per cluster can result in different convergence times per cluster. - The sync timer can be set differently per cluster. - The maximum sync time is the sum of the sync timers along the sync path. - The sync path has a maximum of three hops. Each cluster that is a member of an ILS network requires a unique cluster ID. ILS relies on TLS for secure information exchange. - Each potential xnode must trust the Tomcat certificate of all other potential xnodes. - Bulk Certificate Management can be used for certificate exchange Cisco and/or its affiliates. All rights reserved. COLLAB90 v Synchronization timers can be configured differently for each cluster. The maximum number of hops in an ILS network is three. The maximum convergence time for a cluster is the sum of the synchronization timers along the synchronization path. By setting all clusters to an identical synchronization timer, an update that occurs in a cluster will be propagated to all clusters after at least three update intervals. If different synchronization timers are used, then clusters that have the same distance to the origin of the update will be updated at different times. This situation makes it difficult to manage such an implementation. Each cluster that is a member of an ILS network must have a unique cluster ID. ILS relies on Transport Layer Security (TLS) for secure information exchange. TLS can be based on certificates or a shared password that is configured at all clusters that participate in the ILS network. In the case of certificates, each potential xnode must trust the Tomcat certificate of all other potential xnodes. The simplest way to exchange the certificates is to use Bulk Certificate Management Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

15 URI Syncing-Related Considerations This section describes URI syncing-related considerations. ILS-learned and imported URIs cannot be assigned a partition. - Local URIs of accessible partitions always have priority. - ILS URIs have priority over lookup of the host portion in SIP route patterns. ILS message exchange is totally independant of SIP route patterns and SIP trunks. - ILS only populates the URI call routing table. - ILS is not used for actual call setups (sending INVITE messages). - SIP route patterns and SIP trunks must be statically configured. Since Cisco Unified Communications Manager version 9, a SIP route pattern can refer to a route list. - The route list allows the configuration of a prioritized list of SIP trunks. - The route list enables the configuration of backup paths Cisco and/or its affiliates. All rights reserved. COLLAB90 v ILS-learned and imported URIs cannot be assigned a partition. Locally configured URIs always have priority over ILS URI routing table entries. However, locally configured URIs can be assigned a partition, and therefore not all URIs may be visible to the calling device. ILS URI routing table entries always have priority over a lookup of the host portion against the accessible SIP route patterns. Only if the route string that is associated with a matched ILS URI is not found in any accessible SIP route pattern, the host portion of the URI is matched against the accessible SIP route patterns. Note SIP route patterns can be assigned a partition. SIP route patterns in partitions that are not included in the CSS of the calling devices are ignored. ILS information exchange is totally independent of the signaling message exchange. ILS and URI syncing only populate the ILS URI routing table, but ILS is not used for actual call setups (sending SIP messages such as INVITE). SIP route patterns and SIP trunks must be configured to make the call setup to another cluster work, but they are not required for URI syncing to be successful. Since Cisco Unified Communications version 9, a SIP route pattern can also refer to a route list. By referring to a route list, more than one SIP trunk can be associated with a SIP route pattern to configure backup paths Cisco Systems, Inc. Implementing Intercluster Lookup Service 11-15

16 Using Session Management Edition in an ILS Network This section describes how Cisco Unified Communications Manager Session Management Edition can be used in an ILS network. SIP Route Pattern: * -> SME-ICT SIP Trunk: SME-ICT -> SME Leaf1 ILS Spoke Route String: l1.cisco.com SME ILS Hub Leaf2 ILS Spoke Route String: l2.cisco.com SIP Route Pattern: * -> SME-ICT SIP Trunk: SME-ICT -> SME SIP Route Pattern: * -> SME-ICT SIP Trunk: SME-ICT -> SME Route String: l3.cisco.com Leaf3 ILS Spoke SIP Route Patterns: l1.cisco.com -> L1-ICT l2.cisco.com -> L2-ICT l3.cisco.com -> L3-ICT l4.cisco.com -> L4-ICT SIP Trunks: L1-ICT -> Leaf1 L2-ICT -> Leaf2 L3-ICT -> Leaf3 L4-ICT -> Leaf4 Route String: l4.cisco.com Leaf4 ILS Spoke SIP Route Pattern: * -> SME-ICT SIP Trunk: SME-ICT -> SME 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v When using Cisco Unified Communications Manager Session Management Edition for centralized call processing and monitoring and implementing ILS, the Session Management Edition cluster should be configured as an ILS hub, and all leaf clusters should be configured as ILS spokes. Each ILS spoke is configured with a unique route string. The SIP route pattern configuration at the spokes is very simple. Each cluster has a single SIP route pattern (see the asterisk [*] in the figure), which refers to the only configured SIP trunk that points to the Session Management Edition cluster. At the Session Management Edition cluster, you configure one SIP route pattern and one SIP trunk per ILS spoke cluster. The figure shows an example of an ILS network with a Session Management Edition cluster. Only the spokes have registered endpoints, and the URIs of these endpoints are advertised with a cluster-specific route string Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

17 ILS Implementation This topic describes how to implement ILS. 1. Configure a globally unique enterprise cluster ID. 2. Configure membership of an ILS network: a) Configure the first hub. b) Configure additional hubs. c) Configure spokes. 3. Exchange Tomcat certificates of all potential xnodes (optional). 4. Configure the synchronization interval. 5. Verify remote clusters using the cluster view Cisco and/or its affiliates. All rights reserved. COLLAB90 v This section illustrates the ILS networking configuration procedure, which consists of the following steps: Step 1 Step 2 Step 3 Step 4 Step 5 Configure a globally unique enterprise cluster ID. Configure membership of an ILS network: Configure the first hub. Configure additional hubs. Configure spokes. Exchange Tomcat certificates of all potential xnodes (optional). Configure the synchronization interval. Verify remote clusters using the cluster view Cisco Systems, Inc. Implementing Intercluster Lookup Service 11-17

18 Step 1: Configure the Cluster ID The figure shows the configuration of the cluster ID. The cluster ID must be globally unique when using ILS Cisco and/or its affiliates. All rights reserved. COLLAB90 v The cluster ID is an enterprise parameter and must be set to a unique value when using ILS Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

19 Step 2a: Configure the First Hub Cluster The figure shows the configuration of the first hub cluster. Change the role from Stand Alone Cluster to Hub Cluster. Choose the certificate or password-based ILS authentication. Click the + sign and select cluster members that should run ILS Cisco and/or its affiliates. All rights reserved. COLLAB90 v The first ILS hub cluster is configured as follows: Choose Advanced Features > ILS Configuration. Change the role of the cluster from Stand Alone Cluster to Hub Cluster. Select the ILS authentication method (certificate or password). Note All clusters of an ILS network must share the same authentication method. In the case of password-based authentication, the password must be the same on all clusters. You can click the plus symbol (+) link at the item Server Activation to choose the servers of the cluster on which you want to activate the ILS feature service. After clicking Save, a pop-up window will appear asking for the registration server. Because this is the first ILS hub cluster, leave the registration server field empty Cisco Systems, Inc. Implementing Intercluster Lookup Service 11-19

20 Step 2b: Configure an Additional Hub This section describes how to add an additional ILS hub cluster to the ILS network. After changing the role from Stand Alone Cluster to Hub Cluster, the registration server must be entered. Enter the IP address of the first hub cluster server running ILS Cisco and/or its affiliates. All rights reserved. COLLAB90 v Additional ILS hub clusters are added to an existing ILS network as follows: Choose Advanced Features > ILS Configuration. Change the role of the cluster from Stand Alone Cluster to Hub Cluster. Choose the ILS authentication method (certificate or password). Note The ILS authentication method and the password, if used, must match on all clusters in the same ILS network. You can click the plus symbol (+) link at the item Server Activation to choose the servers of the cluster on which you want to activate the ILS feature service. After clicking Save, a pop-up window will appear asking for the registration server. Enter the IP address of any server of the first ILS hub cluster where the ILS feature service has been activated Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

21 Step 2c: Configure a Spoke This section describes how to add an ILS spoke cluster to the ILS network. After changing the role from Stand Alone Cluster to Spoke Cluster, the registration server must be entered. Enter the IP address of the hub cluster server running ILS Cisco and/or its affiliates. All rights reserved. COLLAB90 v ILS spoke clusters are added to an existing ILS network as follows: Choose Advanced Features > ILS Configuration. Change the role of the cluster from Stand Alone Cluster to Hub Cluster. Choose the ILS authentication method (certificate or password). You can click the plus symbol (+) link at the item Server Activation to choose the servers of the cluster on which you want to activate the ILS feature service. After clicking Save, a pop-up window will appear asking for the registration server. Enter the IP address of any server of the ILS cluster that acts as a hub to the currently configured spoke cluster where the ILS feature service has been activated Cisco Systems, Inc. Implementing Intercluster Lookup Service 11-21

22 Step 3: Exchange Tomcat Certificates This section describes how to exchange Tomcat certificates between all potential xnodes. The simplest way to exchange Tomcat certificates is by using Bulk Certificate Management. It is only required if certificate-based ILS authentication is chosen Cisco and/or its affiliates. All rights reserved. COLLAB90 v When the ILS authentication method must be set to Use TLS Certificates, then you must export the Tomcat certificate of each server that could be designated as an xnode. Then you must import the Tomcat certificates of all other potential xnodes at each potential xnode. These certificates can be imported, one by one, by using Cisco Unified Operating System Administration or by using Bulk Certificate Management Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

23 Step 4: Configure the Synchronization Interval This section describes how to set the synchronization interval at an ILS cluster. If desired, change the synchronization interval (default: 10 minutes) Cisco and/or its affiliates. All rights reserved. COLLAB90 v At the ILS Configuration page, you can change the synchronization interval. The default is 10 minutes. Note The synchronization interval is configured per cluster. It is recommended that you use the same value at all clusters of an ILS network Cisco Systems, Inc. Implementing Intercluster Lookup Service 11-23

24 Step 5: Verify ILS Networking Using Cluster View This section shows how to verify ILS networking configuration and operation. Select the remote cluster Cisco and/or its affiliates. All rights reserved. COLLAB90 v You can view remote clusters and their services by choosing Advanced Features > Cluster View. The cluster view lists all remote clusters that provide services to the local cluster. If you click an entry, the services that are available at this cluster are listed. Note The cluster view was utilized for EMCC only before Cisco Unified Communications Manager version 9. Beginning with version 9, it also shows services such as link bandwidth management, UDS, and ILS (if enabled) Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

25 ILS-Based URI Routing Configuration Procedure This section describes how to configure ILS-based URI routing. Configure URI syncing: 1. Enable URI syncing via ILS. 2. Configure a globally unique route string. Configure URI routing: 1. Configure route groups and route lists (optional). 2. Configure SIP profiles. 3. Configure SIP trunks. 4. Configure SIP route patterns Cisco and/or its affiliates. All rights reserved. COLLAB90 v In order to implement ILS-based URI routing, you must join the participating clusters into an ILS network. The related configuration steps were shown at the beginning of this topic. In addition to a functioning ILS network, you must enable URI syncing and configure URI routing including SIP trunks, route lists (optional), and SIP route patterns. The URI routing configuration procedure is the same for a deployment with ILS or without ILS. In an ILS deployment, you must make sure that the SIP route patterns match the ILS route strings and not the host portion of the dialed URIs. Note The configuration of SIP route patterns and SIP trunks was explained in an earlier lesson of this training. The URI syncing configuration procedure consists of two steps: Step 1 Step 2 Enable URI syncing via ILS. Configure the route string to be associated with the local URIs when they are advertised by ILS Cisco Systems, Inc. Implementing Intercluster Lookup Service 11-25

26 Enable URI Syncing and Configure the Route String The figure shows how to enable URI syncing and how to configure the route string that will be advertised along with the locally configured URIs. Enable URI syncing. Set the route string Cisco and/or its affiliates. All rights reserved. COLLAB90 v Perform the following steps to enable URI syncing: Choose Call Routing > Intercluster Directory URI > Intercluster Directory URI Configuration. Check the Exchange Directory URI Catalogs with Remote Clusters check box. Enter the route string to be used by the currently configured cluster Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

27 ILS Monitoring This topic describes how to monitor ILS operation. Command utils ils findroutestring uri utils ils lookup uri utils ils findxnode utils ils showpeerinfo Description Displays all route strings that are associated with the specified URI. Displays the route string that is used to route a call to the specified URI. Displays the current xnode of the local cluster. Displays information such as the route string, enterprise cluster ID, and role (hub versus spoke) about ILS peers Cisco and/or its affiliates. All rights reserved. COLLAB90 v ILS operation can be monitored using the CLI of any server where the ILS feature service has been activated. The table shows the ILS-related commands and their functions. In a correctly configured ILS deployment, there should be only one route string for a given URI. In other words, a URI should not be present in more than one cluster. If there were multiple route strings that are associated with the specified URI, the first command would display all of them. Therefore, the first command is ideal to troubleshoot routing issues that are caused by duplicate ILS URIs. The second command displays the route string that is used to route a call to the specified URI. Even if multiple route strings were associated with the specified URI, the second command would only display one route string. The third command identifies the xnode of the cluster. Knowing which server has been designated as the xnode is important when troubleshooting of the ILS exchange with remote clusters is required, because only the xnode is actively participating in this exchange. Typically, you would use the third command to identify the xnode and then start tracing ILS on this cluster node. The last command shows the details of ILS peers. This command includes the route string, the enterprise cluster ID, and the role of a specified ILS peer Cisco Systems, Inc. Implementing Intercluster Lookup Service 11-27

28 ILS Alarms This section lists and describes the alarms that are available to monitor ILS. The following ILS-related alarms have been added to Cisco Unified Communications Manager version 9: TLSAuthenticationFailed TCPInUse TCPListenError ILSHubClusterUnreachable ILSRemoteHostUnresponsive ILSProtocolVersion ILSUnacceptableConnectionAttempt ILSDuplicateURIOnLookup ILSDuplicateURIOnReplication 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v These ILS-related alarms have been added to Cisco Unified Communications Manager version 9: TLSAuthenticationFailed: This alarm indicates that a certificate was received that has not been installed locally, and the fully qualified domain name (FQDN) is not a known remote cluster. This case fails the authentication requirements. TCPInUse: This alarm returns all of the route strings that are associated with the URI, including the local cluster. It can be used to troubleshoot problems involving duplicate URIs. TCPListenError: This alarm is raised if the ILS port (7501 by default) is already in use when ILS starts up and attempts to bind to it. ILSHubClusterUnreachable: This alarm is raised when a connection to a hub cluster cannot be established. This alarm will be raised on the xnode. ILSRemoteHostUnresponsive: This alarm is raised when a connection to another cluster is unexpectedly lost. This alarm will be raised on the xnode. ILSProtocolVersion: This alarm is raised when two clusters are running incompatible versions of ILS. They will not be able to communicate and share cluster information or URIs. ILSUnacceptableConnectionAttempt: This alarm is raised in the following scenarios: A new cluster attempted to join, but the local cluster is not configured as a hub. An unknown cluster has attempted to connect without first registering to the ILS network. Data corruption in the network packet can also cause this alarm Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

29 ILSDuplicateURIOnLookup: This alarm is raised when a URI lookup results in more than one routing string. This alarm is raised on any node that runs ILS. ILSDuplicateURIOnReplication: This alarm is raised when a URI from a remote cluster is replicated in and matches a local URI. Note Because of performance effects, the check for a match on a local URI is not performed by default, and therefore the alarm will never activate. If needed, Cisco Technical Assistance Center (TAC) will provide you with instructions on how to enable the check. This alarm is operational only when this check is enabled Cisco Systems, Inc. Implementing Intercluster Lookup Service 11-29

30 Summary This topic summarizes the key points that were discussed in this lesson. ILS is a new feature that was introduced in Cisco Unified Communications Manager version 9 that enables intercluster URI routing with overlapping URI host portions. All clusters that should exchange ILS information must be joined into the same ILS network. URI syncing allows clusters that are part of an ILS network to exchange their local URIs along with a cluster-specific route string. ILS-learned URIs are only considered if the called URI is not found in the local database. ILS implementation steps include ILS network and URI syncing configuration tasks. ILS monitoring options include alarms and CLI commands Cisco and/or its affiliates. All rights reserved. COLLAB90 v References This lesson described how ILS works and how it is implemented. The lesson started with an overview of ILS and then described the functions of ILS networking and URI syncing. The lesson then explained what needs to be considered when implementing ILS and how to configure ILS. Finally, the lesson described how to monitor ILS operation. For additional information, refer to this resource: Cisco Systems, Inc., Cisco Unified Communications Manager Features and Services Guide, Release 9.1(1), section Intercluster Lookup Service at: K_C3E0EFA0_00_cucm-features-services-guide-91_chapter_ html Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

31 Appendix 12 Implementing Advanced SIP Solutions Overview Objectives This lesson provides an overview of advanced Session Initiation Protocol (SIP) implementations. It describes SIP features and functions, endpoint registration options, and includes considerations when implementing SIP with other vendors. The end of this lesson focuses on troubleshooting advanced SIP implementations. Upon completing this lesson, you will be able to implement advanced SIP solutions, including multivendor environments. This ability includes being able to meet these objectives: Describe advanced SIP implementation List and describe the SIP features and functions Describe the options for SIP endpoint registration in Cisco Unified Communications Manager version 9 Troubleshoot advanced SIP solutions

32 Overview of Advanced SIP Implementations This topic provides an overview of SIP. SIP is an IETF standard. It creates, modifies, and terminates multimedia sessions with one or more participants It is supported on all Cisco collaboration endpoints. It is a peer-to-peer architecture: - UAC initiates SIP requests. - UAS returns SIP responses. - Phones, gateways, and Cisco call control devices can be UAs. SIP uses ASCII text-based messages 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v The IETF developed SIP. SIP is a peer-to-peer, common standard protocol that is based on the logic of the World Wide Web and very simple to implement. SIP is designed to address the functions of signaling and session management. It is widely used with proxy servers, gateways, phones, and Internet telephony service providers (ITSPs). Through invitations, SIP initiates sessions or invites participants into established sessions. Descriptions of these sessions are advertised by any one of several means, including the Session Announcement Protocol (SAP). SAP incorporates a session description according to the Session Description Protocol (SDP). The user agent (UA) is a combination of the user agent client (UAC) and the user agent server (UAS) that initiates and receives calls. A UAC initiates a SIP request. A UAS, which is a server application, contacts the user when it receives a SIP request. The UAS then responds on behalf of the user. Cisco Unified Communications Manager can act as both a server and a client (a back-to-back user agent) Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

33 SIP Trunk Overview This subtopic provides an overview of SIP trunks. SIP trunks provide connectivity to other SIP devices: - Gateways - Cisco Unified CM Session Management Edition - SIP proxies - Other Cisco Unified CM clusters - Third-party vendors SIP trunk and call routing enhancements: - Can run on all Cisco Unified CM nodes - Up to 16 destination IP addresses per trunk - SIP early offer support for voice and video calls (insert MTP, if needed) - Audio codec preference (Accept Audio Codec Preference in Received Offer) - SIP trunk normalization and transparency - Supports the use of route lists on all Cisco Unified CM nodes 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v SIP trunks provide connectivity to other SIP devices such as gateways, Cisco Unified Communications Manager Session Management Edition, SIP proxies, Cisco Unified Communications applications, and other Cisco Unified Communications Manager clusters. Today, SIP is arguably the most commonly chosen protocol when connecting to service providers and Cisco Unified Communications applications. Cisco Unified Communications Manager provides the following SIP trunk and call routing capabilities: Can run on all Cisco Unified Communications Manager nodes Up to 16 destination IP addresses per trunk SIP early offer support for voice and video calls with media termination point (MTP) insertion only if needed Audio coder-decoder (codec) preference lists and option to accept audio codec preference in received offer SIP trunk normalization and transparency Supports the use of route lists on all Cisco Unified Communications Manager nodes The SIP trunk features that are available in the current release of Cisco Unified Communications Manager make SIP the preferred choice for new and existing trunk connections. The ability to run on all Cisco Unified Communication Manager nodes and to manage up to 16 destination IP addresses improves outbound call distribution from Cisco Unified Communications Manager clusters and reduces the number of SIP trunks that are required between clusters and devices. SIP early offer support for voice and video calls (insert MTP, if needed) can reduce or eliminate the need to use MTPs and allows voice, video, and encrypted calls to be made over SIP early offer trunks Cisco Systems, Inc. Implementing Advanced SIP Solutions 12-3

34 Review of SIP Features and Functions This topic describes SIP features and functions. Determines the location of the destination endpoint Determines the media capabilities of the destination endpoint - SDP establishes the best common service level Determines the availability of the destination endpoint and informs the reason of termination - Not reachable - Busy - No answer Establishes a session between participant endpoints Manages the transfer and termination of calls 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v SIP supports five key functions when establishing a communication: SIP determines the location of the destination endpoint: Address resolution Name mapping Call redirection SIP determines the media capabilities of the destination endpoint. SDP message codec negotiation is used to determine the best codec that is common between endpoints. SIP determines the availability of the destination endpoint. SIP determines whether the called party is already connected to a call or did not answer. If the call cannot be completed, SIP returns a message that indicates the reason why the target endpoint was unavailable. SIP establishes a session between participant endpoints. When the call can be completed, SIP establishes a session between the endpoints. SIP manages the transfer and termination of calls. During a call, SIP establishes a session between the transferee and a new endpoint. SIP tears down the session between the endpoints when the call is terminated Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

35 SIP Call Setup This topic describes how a basic SIP call is set up and terminated in a Cisco Unified Communications Manager deployment. 1. INVITE (SDP) [email protected] Trying 2. INVITE (SDP) [email protected] Ringing Ringing OK OK 6. ACK 6. ACK AUDIO VIDEO 7. Media (UTP) 8. BYE 8. BYE OK OK 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v This figure depicts the call setup and teardown between two SIP endpoints. SIP call setup proceeds as follows: Step 1 The originating endpoint sends an invitation (INVITE) to the Cisco Unified Communications Manager. The message includes the SDP description of the supported media parameters. Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 The Cisco Unified Communications Manager forwards this invitation to the targeting endpoint. The originating endpoint receives a 100 Trying message from Cisco Unified Communications Manager, which indicates that the INVITE was sent to the targeting endpoint. The terminating endpoint sends the ringing signal to the originating endpoint. The call is taken off-hook. If the targeting endpoint determines that the call parameters are acceptable, it responds to the originator using the 200 OK message. The originating endpoint issues an acknowledgment (ACK) to the targeting endpoint. A Real-Time Transport Protocol (RTP) or UDP session is established between the endpoints. The originating endpoint terminates the call, and the BYE message is sent to the targeting endpoint via Cisco Unified Communications Manager. The remote endpoint confirms the BYE message with 200 OK messages, which is also exchanged via Cisco Unified Communications Manager Cisco Systems, Inc. Implementing Advanced SIP Solutions 12-5

36 Session Description Protocol SDP is part of a SIP message. SDP describes session parameters in a SIP message. SDP contains the following: - Type of media (audio and media) - Transport protocol (RTP or UDP or IP and H.230) - Media format (codecs) A list of supported media formats is offered: - All listed formats may be used in the session. SIP exchanges codecs at different stages in call setup: - Delayed offer: 200 OK and ACK - Early offer: Invite and 200 OK - Early media: 183 Session Progress, 180 Ringing, Pre-Ack 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v SDP is an IETF-based format for describing streaming media initialization parameters. SDP is intended for describing multimedia communication sessions for the purposes of session announcement, session invitation, and parameter negotiation. SDP does not deliver media itself but is used for negotiation between endpoints of media type, format, and all associated properties. SDP is designed to be extensible to support new media types and formats. SIP uses SDP to negotiate the type of media (audio and video), the transport protocol (RTP), and the media format (audio and video codecs). The originating endpoint provides a selection list of supported codecs, which is ordered by highest priority. The targeting endpoint chooses an offer that matches its capabilities. SIP uses the Offer-Answer model to establish SIP sessions, and SIP can exchange codecs at different stages in the call setup Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

37 Example: Audio, RTP/49174, G.711 mulaw Video, RTP/49170, H261 v=0 o=bob IN IP4 host1.cisco.com s=example c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video RTP/AVP 31 a=rtpmap:31 H261/90000 Field Description Version v=0 Origin o=<username> <session id> <version> <network type> <address type> <address> Session s=<session name> name Connection data Times Media Audio Video Profile (AVP) codes c=<network type> <address type> <connection address> t=<start time> <stop time> m=<media> <port> <transport> <media format list> 0: G.711 mu-law 8: G.711 a-law 3: GSM codec 18: G : H Cisco and/or its affiliates. All rights reserved. COLLAB90 v This figure is an example of SDP. The table explains the parameters that are used in the example: Version: This parameter is the protocol version. Origin: This parameter describes the originator of the message. Session name: This parameter is a mandatory name with at least one UTF-8-encoded character. Times: This parameter includes the start and end time of a session. Connection data: This parameter provides the parameters for media endpoint termination: network type (IN is defined as Internet), address type (IPv4 or IPv6), and the connection address (IP address). Media: This parameter specifies the media type (audio or video), the UDP transport port, and all offered media formats. Examples of Audio Video Profile (AVP) codes are 0 (G.711 mu-law), 8 (G.711 a-law), 3 (GSM codec), 18 (G.729), and 31 (H.261). Offered codecs are ordered according to the priority (from most preferred to least preferred) Cisco Systems, Inc. Implementing Advanced SIP Solutions 12-7

38 Delayed Offer Delayed offer is one method of negotiating media. 1. INVITE Trying 2. INVITE Ringing Ringing OK (SDP: Media Offer) OK (SDP: Media Offer) 6. ACK (SDP: Media Answer) 6. ACK (SDP: Media Answer) AUDIO VIDEO Media (UTP) 7. BYE 7. BYE OK OK 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v In a delayed offer, the session initiator does not send its media capabilities in the INVITE message but waits for the called device to send its capabilities first. The codec that is used in this scenario is determined by the targeting endpoint. The originating endpoint receives the codec priority list from the targeting endpoint and compares the list with its own codec priority list, which is configured in regional settings. The codec priority list is compared from the first (prioritized) codec to the last (least prioritized) codec. The first prioritized codec that is supported by both endpoints is chosen to negotiate the call. Note Cisco gateways support the delayed offer as well, but an originating gateway defaults to the early offer Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

39 Early Offer The INVITE message contains the SDP media offer when the call is initialized. 1. INVITE (SDP: Media Offer) Trying 2. INVITE (SDP: Media Offer) Ringing Ringing OK (SDP: Media Answer) OK (SDP: Media Answer) 6. ACK 6. ACK AUDIO VIDEO Media (UTP) 7. BYE 7. BYE OK OK 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v When using early offer, the session initiator sends its capabilities (including the supported codecs) in the SDP, which is contained in the initial INVITE message. This method allows the called device to choose its preferred codec for the session. Early offer is the default method that is used by Cisco Unified Border Element when acting as the originating gateway. To enable early offer on Cisco Unified Communications Manager, the SIP profile must be adjusted appropriately Cisco Systems, Inc. Implementing Advanced SIP Solutions 12-9

40 Early Media Sending of media can be allowed before the call is accepted. 183 Session Progress Option 1. INVITE Trying 2. INVITE Session Progress (SDP: MO) Session Progress (SDP: Media Offer) 5. Pre-ACK (SDP: Media Response) 5. Pre-ACK (SDP: Media Response) Ringing Ringing AUDIO VIDEO Media (UTP) OK OK 8. ACK 8. ACK 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v Early media allows the sending of media from the called party or an application server to the caller, even before the call is accepted. The most common reasons for using early media include the following: The called device might want to establish an early media RTP path to reduce the effects of audio cut-through delay (clipping) for calls that experience long signaling delays or to provide a network-based voice message to the caller. The calling device might want to establish an early media RTP path to access a dual tone multifrequency (DTMF) or voice-driven interactive voice response (IVR) system. Cisco Unified Communications Manager supports Provisional Reliable Acknowledgement (PRACK)-based early media for both early offer and delayed offer calls. Early two-way media cut-through can be achieved by enabling PRACK on each SIP Cisco Unified Communications system. PRACK allows the SIP offer and answer to be sent reliably in provisional responses (for example, 1XX responses), thus reducing the number of messages that need to be exchanged before two-way media can be established Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

41 180 Ringing Option 1. INVITE Trying 2. INVITE Ringing (SDP: Media Offer) Ringing (SDP: Media Offer) 5. Pre-ACK (SDP: Media Response) 5. Pre-ACK (SDP: Media Response) AUDIO VIDEO Media (UTP) OK OK 8. ACK 8. ACK 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v To facilitate early media with delayed offer, the IETF draft allows the use of messages other than the 183 Session Progress response. Some implementations use the 180 Ringing response to send the initial SDP media offer. The 180 Ringing message is a provisional or informational response that is used to indicate that the INVITE message has been received by the user agent and that alerting is taking place Cisco Systems, Inc. Implementing Advanced SIP Solutions 12-11

42 Media Termination Point If DTMF between endpoints is inconsistent, an MTP can be dynamically located. An MTP can be configured to be used on the following at all times: - Lines - Trunks By default, it is not used by any SIP device. It is dynamically located when the DTMF method between connected devices is not compatible. SIP IP Phone PRI Gateway TDM PSTN RTP Stream RTP Stream MTP 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v MTPs are used by Cisco Unified Communications Manager to accomplish the following goals: Deliver a SIP early offer over SIP trunks Address DTMF transport mismatches Act as an RSVP agent Act as a trusted relay point (TRP) Provide conversion between IPv4 and IPv6 for voice RTP streams Either of the following methods can be used to enable early offer on SIP trunks: Check the MTP Required check box on the SIP trunk. In this case, an MTP is used for every outbound call, and only voice calls are supported. You can choose MTP Preferred Originating Codec from the drop-down list under SIP trunk configuration. Check the Early Offer Support for Voice and Video Calls (Insert MTP If Needed) check box on the SIP profile that is associated with the SIP trunk. With this method, an MTP is inserted only if the calling device or trunk cannot send all of the information about its media capabilities in the initial SIP invite (for example, an inbound call to Cisco Unified Communications Manager from a SIP delayed offer or H.323 Slow Start trunk). In this case, when an MTP is used, additional voice codecs can be supported in the initial call setup by using the pass-through codec of the MTP. Once established, this audio call can be escalated to support video and encryption if the media of the call is renegotiated (for example, after hold or resume). When an MTP is not needed, all calls support voice, video, and encrypted media Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

43 SIP Endpoint Registration Options This topic describes feature support in Cisco SIP IP phones. When using SIP on a Cisco IP phone, only basic features are supported on Type-A IP phones: - Cisco IP Phones 7905, 7912, 7940, and 7960 have end-of-life status and can no longer be purchased. On newer IP phones, most of the features are supported when using SIP: - Cisco Unified IP Phones 794(25), 796(25), and Cisco Unified IP phones with SIP-only support: - Cisco Unified IP Phones 8961, 9951, and Third-party IP phones support limited features when registered to Cisco Unified Communications Manager. Blended addressing is not supported with Type-A IP phones Cisco and/or its affiliates. All rights reserved. COLLAB90 v Type-A Cisco IP phones support basic features when using SIP firmware. Supported features are Answer Release, Auto Answer, Call Forward, Call Waiting, Caller ID, Conference, Do Not Disturb, Help System, Hold/Resume, Mute, Redial, Speed Dialing, Transfer, and Voice Mail. Other features are not supported or have only limited support. Note Cisco IP Phones 7905, 7912, 7940, and 7960 have end-of-life status and can no longer be purchased. On newer Cisco IP phones, there are very few features unsupported when using SIP. Blended addressing is supported by these IP phones, and it is enabled by default on Cisco Unified Communications Manager. Note Blended addressing will insert both the directory URI and the directory number of the sending party in outgoing SIP invites. Third-party SIP phones register with Cisco Unified Communications Manager but do not use a MAC address-based device ID. User-based registration must be used to identify a registering third-party SIP phone. Configuration for SIP registration needs to be done on Cisco Unified Communications Manager and on third-party SIP phones Cisco Systems, Inc. Implementing Advanced SIP Solutions 12-13

44 Third-Party SIP Endpoints This subtopic describes SIP features for third-party SIP endpoints. Third-party SIP IP phones support only a few features compared with Cisco SIP IP phones. The features that are not supported are the following: - MAC address registration - Phone button templates - Softkey templates - Telephony features and applications: Cisco Unified Video Advantage Cisco Unified Communications Manager Assistant Cisco IP Phone Services Call Pickup Barge Cisco Unified Presence 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v The limitations of third-party SIP endpoints include, but are not limited to, the following: MAC address-based registration. SIP phones must be configured and associated with the user information that is used for phone registration (user ID and extension number) instead of a MAC address-based device ID. There is no support for phone templates and softkey templates. The user interface depends on the SIP product that is used. Telephony features and applications such as the following are not supported: Cisco IP Phone Services Cisco Unified Communications Manager Assistant Cisco Unified Video Advantage Call Pickup Barge Cisco Unified Presence Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

45 Cisco SIP IP Phones SIP-only Cisco IP phones support a large number of features. Cisco Unified IP Phones 8961, 9951, and 9971 support only the SIP protocol. Features that are supported when registering these IP phones to Cisco Unified CM include the following: - Autoregistration - MAC address registration - Phone button templates - Softkey templates - Blended addressing - Video - URI dialing 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v Cisco Unified IP Phones 8961, 9951, and 9971 are SIP-only IP phones that can register to Cisco Unified Communications Manager with the MAC address. For more information about the Cisco Unified IP Phone 8900 and 9900 Series, refer to the following data sheets and product documentation: Cisco Unified IP Phone 8900 Series: Cisco Unified IP Phone 9900 Series: Cisco Systems, Inc. Implementing Advanced SIP Solutions 12-15

46 Cisco SIP IP Phone Registration Prerequisites It is mandatory to choose a phone security profile and a SIP profile. When registering a Cisco SIP IP phone, the following can be preconfigured: - Phone security profile - SIP profile Depending on the type of SIP IP phone, the system parameters must be set. Phone Security Profile SIP Profile (SIP Phones Only) 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v Cisco Unified Communications Manager Administration groups security-related settings in the SIP phone security profile, which works like a template. You will configure the settings in the profile and then apply the profile to the SIP phone. After you apply the profile to the phone, it uses the settings that you configured in the SIP Phone Security Profile window. If you want to do so, you can use the same profile for many SIP phones, which eliminates having to configure the same set of parameters multiple times. The SIP Phone Security Profile window includes security-related settings such as Device Security Mode, Authentication Mode (for CAPF), Key Size (for CAPF), Enable Digest Authentication, Nonce Validity Time, Transport Type, and SIP Phone Port. Note All SIP phones require that you apply a security profile. A SIP profile comprises the set of SIP attributes that are associated with SIP trunks and SIP endpoints. SIP profiles include information such as name, description, timing, retry, call-pickup URI, and so on. The profiles contain some standard entries that cannot be deleted or changed Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

47 Phone Security Profile Configuration The phone security profile must be configured to enable authentication and encryption. Choose System > Security > Phone Security Profile. Find the security profile that contains the IP phone model number in the name field. Click Cisco 9951 Standard SIP Non-Secure Profile. To change the settings of an inbuilt phone security profile, you need to make a copy first and give it a different name Cisco and/or its affiliates. All rights reserved. COLLAB90 v Perform the following steps to configure the phone security profile: Step 1 Step 2 Step 3 Choose System > Security > Phone Security Profile. Find the security profile that contains the IP phone model number in the name field. In this example, click Cisco 9951 Standard SIP Non-Secure Profile to create a phone security profile for the Cisco Unified IP Phone 9951 phone model. Note Step 4 Depending on the chosen phone model, the phone security profile will only include the configuration parameter that is applicable to the chosen phone. Click Copy and name the newly created phone security profile Cisco Systems, Inc. Implementing Advanced SIP Solutions 12-17

48 Device Security Modes: Non Secure Authenticated Encrypted Transport Types in Non Secure Mode: TCP UDP TCP+UDP Transport Types in Secure Mode: TLS To enable Digest Authentication, check this box. Enable IP phone configuration encryption by checking this box Cisco and/or its affiliates. All rights reserved. COLLAB90 v The Phone Security Profile Information provides security configuration options as follows: Device Security Mode Non Secure: This option provides no security features except image, file, and device authentication for the phone. A TCP connection opens to Cisco Unified Communications Manager. Authenticated: Cisco Unified Communications Manager provides integrity and authentication for the phone. Packets are protected against modifications but not against eavesdropping. Encrypted: Cisco Unified Communications Manager provides integrity, authentication, and encryption for the phone. Packets are protected against modifications and against eavesdropping (Secure RTP [SRTP]). Transport Type: When the Device Security Mode is Non Secure, choose one of the following options: TCP: Choose TCP to ensure that packets are received in the exact order in which they are sent. This protocol ensures that no packets are dropped, but the protocol does not provide any security. UDP: Choose UDP to ensure that packets are received quickly. This protocol, which can drop packets, does not ensure that packets are received in the order in which they are sent. This protocol does not provide any security. TCP + UDP: Choose this option if you want to use a combination of TCP and UDP. This option does not provide any security. Transport Type: When Device Security Mode is Authenticated or Encrypted, Transport Layer Security (TLS) can be chosen. TLS provides signaling integrity, device authentication, and signaling encryption (encrypted mode only) for SIP phones Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

49 Enable Digest Authentication: If you check this check box, Cisco Unified Communications Manager challenges all SIP requests from the phone. Digest authentication does not provide device authentication, integrity, or confidentiality. TFTP Encrypted Config: When this check box is checked, Cisco Unified Communications Manager encrypts phone downloads from the TFTP server Cisco Systems, Inc. Implementing Advanced SIP Solutions 12-19

50 SIP Profile Configuration Configure a SIP profile in Cisco Unified Communications Manager Administration. Choose Device > Device Settings > SIP Profile. Click Find, and make a copy of the standard SIP Profile Cisco and/or its affiliates. All rights reserved. COLLAB90 v The SIP profile offers many options to be configured and applied to a SIP phone or SIP trunk. The example shows the configuration of the following options: Default MTP Telephony Event Payload Type: This field specifies the default payload type for an RFC 2833 telephony event. The default value specifies 101 with a range from 96 to 127. If the ITSP is using a different DTMF payload type, you can change it here. Dial String Interpretation: Cisco Unified Communications Manager uses the Dial String Interpretation policy to determine if the SIP identity header is a directory number or directory URI. Because directory numbers and directory URIs are saved in different database lookup tables, it is important to choose the right option that clearly determines the directory number or directory URI. Redirect by Application: Checking this check box and configuring this SIP profile on the SIP trunk allows Multiway functionality to work properly when triggered from remotely registered video telepresence devices. Note Multiway conferencing enables video endpoint users to introduce a third party into an existing call. Disable Early Media on 180: If you do not receive ringback, the device to which you are connecting may include SDP in the 180 response but is not sending any media before the 200 OK response. In this case, check this check box to play a local ringback tone on the calling phone and connect the media upon receipt of the 200 OK response Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

51 When the SIP device is a tablet device, the following parameters should be changed: - Timer Register Delta (seconds): 60 - Timer Register Expires (seconds): Timer Keep Alive Expires (seconds): Timer Subscribe Expires (seconds): Cisco and/or its affiliates. All rights reserved. COLLAB90 v Example of a SIP Profile for Cisco Jabber Running on Tablets The example shows a SIP profile that allows Cisco Jabber running on tablets to stay connected to Cisco Unified Communications Manager while the application is running in the background. To configure the SIP profile, perform the following steps: Step 1 Step 2 Step 3 Step 4 Choose Device > Device Settings > SIP Profile. Create a SIP profile or copy an existing SIP profile. You can name the profile Standard Tablet SIP Profile. In the Parameters Used in Phone section, enter these values: Timer Register Delta (seconds): 60 (default: 5) Timer Register Expires (seconds): 660 (default: 3600) Timer Keep Alive Expires (seconds): 660 (default: 120) Timer Subscribe Expires (seconds): 660 (default: 120) Click Save Cisco Systems, Inc. Implementing Advanced SIP Solutions 12-21

52 SIP Multivendor Implementation Considerations This topic describes how to implement Cisco Unified Communications Manager with multiple vendors via SIP. Internet Telephony Service Provider SIP Trunk SIP Video TelePresence Cisco VCS SIP IP Phone SIP Video Phone SIP Video TelePresence SIP Proxy Third-Party Class 4/5 Switch TelePresence Endpoint with Twin Data Display 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v Cisco Unified Communications Manager supports connecting to numerous vendors and call processing servers via SIP trunks. It supports aggregating different trunk connections and interconnecting them. Cisco Unified Communications Manager can provide redundancy and failover with SIP trunking as well. Cisco Unified Communications Manager only accepts calls from the SIP device whose IP address matches the destination address of the configured SIP trunk. In addition, the port on which the SIP message arrives must match the one that is configured on the SIP trunk Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

53 Cisco Unified Communications Manager Configuration Considerations Configuration of Cisco Unified Communications Manager differs when connecting to different vendors. Cisco Unified Communications Manager supports implementation with numerous vendors using SIP. Implementation comprises the following steps: - Configure your region with an appropriate session bit rate for video calls, if applicable. - Configure a SIP profile for phone devices. - Add SIP IP phone devices. - Configure the device directory number: specify the telephone number that will cause this phone to ring. - Configure the SIP trunk security profile. - Configure the SIP trunk device. - Configure the cluster fully qualified domain name. - Configure a route pattern to route calls to the SIP trunk device. - Configure a SIP route pattern to enable URI dialing Cisco and/or its affiliates. All rights reserved. COLLAB90 v The configuration of Cisco Unified Communications Manager and Cisco phones to enable calls to be made between the phones consists of setting up a SIP profile, specifying the phones on Cisco Unified Communications Manager, giving the phones phone numbers, and getting the phones to load their configuration. This configuration includes the following steps: Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 Configure your region with an appropriate session bit rate for video calls, if applicable. Configure a SIP profile for phone devices. Add SIP IP phone devices. Configure the device directory number: specify the telephone number that will cause this phone to ring. Configure the SIP trunk security profile. Configure the SIP trunk device. Configure the cluster fully qualified domain name (FQDN). Configure a route pattern to route calls to the SIP trunk device. Configure a SIP route pattern to enable URI dialing Cisco Systems, Inc. Implementing Advanced SIP Solutions 12-23

54 Region Configuration To allow better video quality, higher bandwidth needs to be configured in region settings. Choose System > Region Information > Region. Choose the region (for example, the Default region). Set the Maximum Session Bit Rate for Video Calls to a suitable upper limit (for example, 6000 kb/s) Cisco and/or its affiliates. All rights reserved. COLLAB90 v Ensure that your region has an appropriate session bit rate for video calls: Step 1 Step 2 Step 3 Choose System > Region Information > Region. Choose the region (for example, the Default region). Set the Maximum Session Bit Rate for Video Calls to a suitable upper limit (for example, 6000 kb/s). The entries in this column specify the maximum video bit rate (including audio) between the regions that you are configuring and the region that displays in the corresponding row Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

55 SIP Profile for Phone Devices A SIP profile can be applied on endpoints and SIP trunks. Choose Device > Device Settings > SIP Profile. Click Copy against the Standard SIP Profile. Configure the following fields, leaving everything else at its default value. Name Use Fully Qualified Domain in SIP Requests Allow Presentation Sharing Using BFCP Standard SIP Profile for SIP phones Check the check box. Check the check box if BFCP (dual video and presentation sharing) is required Cisco and/or its affiliates. All rights reserved. COLLAB90 v This figure outlines the procedure for creating the SIP profile that will be applied to all phone devices. To create a SIP profile, use the following procedure: Step 1 Step 2 Choose Device > Device Settings > SIP Profile. Click Find and choose Standard SIP Profile. Step 3 Click Copy. Configure the following fields, leaving everything else at its default value: Name: Enter a recognizable name. Use Fully Qualified Domain in SIP Requests: If the box is checked, Cisco Unified Communications Manager will relay an alphanumeric hostname of a caller by passing it through to the called endpoint as a part of the SIP header information. This process enables the called endpoint to return the call using the received or missed call list. If the call is originating from a line device on the Cisco Unified Communications Manager cluster and is being routed on a SIP trunk, then the configured organization top level domain (OTLD) (for example, Cisco.com) will be used in the Identity headers, such as From, Remote-Party-ID, and P-Asserted-ID. Allow Presentation Sharing using BFCP: If the box is checked, Cisco Unified Communications Manager is configured to allow supported SIP endpoints to use the Binary Floor Control Protocol (BFCP) to enable presentation sharing. The use of BFCP creates a media stream in addition to the existing audio and video streams. This additional stream is used to stream a presentation, such as a PowerPoint presentation, from the presenter laptop to a SIP video endpoint Cisco Systems, Inc. Implementing Advanced SIP Solutions 12-25

56 Adding a Phone Device A phone can be added using Cisco Unified Communications Manager Administration. Choose Device > Phone. Click Add New. Choose the SIP profile called Standard SIP Profile for SIP Phones. Configure the other fields as required, such as the MAC address, description, and so on. Click Save and click OK. Click Apply Config and click OK Cisco and/or its affiliates. All rights reserved. COLLAB90 v Use the following procedure to add a phone device: Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Choose Device > Phone. Click Add New. Choose Standard SIP Profile for SIP phones in the SIP profile drop-down list. Configure the other fields as required, such as MAC address, description, and so on. Click Save and click OK. Click Apply Config and click OK. If there is already another phone that is configured, you can copy its configuration. Open a phone configuration page, click Copy, and enter the MAC address of the new phone Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

57 Configuring the Device Directory Number To be able to contact the IP phone, a directory number must be applied to it. Choose Device > Phone. Choose the relevant device name. On the left-hand side, choose a line. Set up the required directory number Cisco and/or its affiliates. All rights reserved. COLLAB90 v Use the following procedure to configure the device directory number: Step 1 Choose Device > Phone. Step 2 Choose the relevant device name. Step 3 On the left-hand side, choose a line. Step 4 Set up the required directory number Cisco Systems, Inc. Implementing Advanced SIP Solutions 12-27

58 Configuring the SIP Trunk Security Profile The SIP trunk security profile can be applied on more than one SIP trunk. Choose System > Security > SIP Trunk Security Profile. Choose Non Secure SIP Trunk Profile. Modify the fields as shown: Click Save Cisco and/or its affiliates. All rights reserved. COLLAB90 v Perform the following steps to configure the SIP trunk security profile: Step 1 Step 2 Step 3 Choose System > Security > SIP Trunk Security Profile. Choose Non Secure in the Device Security Mode drop-down list. Modify the fields as follows: Accept Unsolicited Notification: If you want Cisco Unified Communications Manager to accept incoming non-invite, unsolicited notification messages that come via the SIP trunk, check this check box. This setting is required for the Message Waiting Indicator (MWI) to work over a SIP trunk. Accept Replaces Header: If you want Cisco Unified Communications Manager to accept new SIP dialogs that replace existing SIP dialogs, check this check box. You must enable Accept Replaces Header if you want to support application call transfers. For example, this approach allows REFER w/replaces to be passed, which is used by supervised transfers that are initiated by Cisco Unity. Note Step 4 The REFER method is a SIP extension request that indicates that the recipient (identified by the Request-URI) should contact a third party using the contact information that is provided in the request. Click Save Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

59 Configuring the SIP Trunk Device To allow incoming calls from other call controls, a SIP trunk must be added. Choose Device > Trunk. Click Add New. Choose SIP Trunk as the Trunk Type. - Device Protocol displays SIP. - Choose None(Default) as the Trunk Service Type. Click Next. Configure all of the fields as shown in the following slides. Click Save. Click Reset Cisco and/or its affiliates. All rights reserved. COLLAB90 v SIP trunks (or signaling interfaces) connect Cisco Unified Communications Manager clusters with a SIP proxy server. The SIP signaling interface uses requests and responses to establish, maintain, and terminate calls (or sessions) between two or more endpoints. Follow these steps to configure the SIP trunk device: Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Choose Device > Trunk. Click Add New. Choose SIP Trunk as the Trunk Type: Device Protocol displays SIP. Choose None (Default) as the Trunk Service Type. Click Next. Configure all of the fields as shown in the next figure. Click Save. Click Reset Cisco Systems, Inc. Implementing Advanced SIP Solutions 12-29

60 Configure the Device Information fields as shown: 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v The configuration of the SIP trunk depends on the remote site prerequisites. Different vendors require different configurations on the SIP trunk. Device Information contains basic and security-related configuration. Commonly used fields are the following: Device Name: Enter a unique identifier for the trunk. Device Pool: Choose the appropriate device pool for the trunk. Among other settings, device pools specify a list of up to three Cisco Unified Communications Manager servers. Call Classification: This parameter determines whether an incoming call through this trunk is considered off the network (off-net) or on the network (on-net). This field provides tool fraud protection for off-net to off-net calls in conjunction with the service parameter Block Off-Net to Off-Net Transfer when set to true. Location: Choose the appropriate location for the trunk. The location specifies the total bandwidth that is available for calls coming into the location or going out of the location. A location setting of Hub_None specifies unlimited available bandwidth. Packet Capture Mode: This setting exists for troubleshooting encryption only; packet capturing may cause high CPU usage or call-processing interruptions. Leaving this parameter at None will ensure that no packet capturing is occurring. Media Termination Point Required: Clear this check box if any videophones that are registered to Cisco Unified Communications Manager will make or receive video calls with video-enabled endpoints that are registered to the remote site. Checking this option on the SIP trunk assigns an MTP for every outbound call. This statically assigned MTP supports only the G.711 codec or the G.729 codec, thus limiting media to voice calls only. SRTP Allowed: If you want to use authentication and encryption over the SIP trunk, then this check box must be checked Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

61 Run On All Active Unified CM Nodes: When this option is checked, Cisco Unified Communications Manager creates an instance of the SIP trunk daemon on every callprocessing subscriber within the cluster, thus allowing SIP trunk calls to be made or received on any call-processing subscriber. Prior to this feature, only up to three nodes could be selected per trunk by using Unified CM Groups, which are applied via the device pool Cisco Systems, Inc. Implementing Advanced SIP Solutions 12-31

62 Configure the Call Routing Information > Inbound Calls fields as shown: Configure the Call Routing Information > Outbound Calls fields as shown: 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v The Call Routing Information section must be configured accordingly to dialing rules. Commonly used fields are as follows: Redirecting Diversion Header Delivery Inbound: Check this check box to accept the Redirecting Number Information Element in the incoming SETUP message to the Cisco Unified Communications Manager. Calling Party Selection: Choose the directory number that is sent on an outbound call on a gateway. The originator sends the directory number of the calling device. Redirecting Diversion Header Delivery Outbound: Check this check box to include the Redirecting Number Information Element in the outgoing SETUP message from the Cisco Unified Communications Manager to indicate the first redirecting number and the redirecting reason of the call when the call is forwarded. Many ITSPs support forwarding a call with the calling number being unrecognized, as long as the diversion header contains the subscriber number Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

63 Configure the SIP Information fields as shown: 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v The SIP Information section contains the configuration parameters that describe how to access the remote call control system. Commonly used fields are as follows: Destination Address is an SRV: This field specifies that the configured destination address is a Domain Name System (DNS) service (SRV) record. Note A DNS SRV record allows administrators to use several servers for a single domain name. Destination Address: This field is the IP address of the remote device to which this SIP trunk points. SIP Trunk Security Profile: Choose the security profile to apply to the SIP trunk. SIP Profile: From the drop-down list box, choose the SIP profile that is to be used for this SIP trunk. DTMF Signaling Method: By placing a restriction on the DTMF signaling method across the trunk, Cisco Unified Communications Manager is forced to allocate an MTP if any one or both of the endpoints do not support a named telephony event (NTE). In this configuration, the only time an MTP will not be allocated is when both endpoints support NTEs. If all of the remote endpoints support NTE (RFC 2833), then configuring this option will not allow Cisco Unified Communications Manager to send any Keypad Markup Language (KPML) (or Unsolicited Notify) DTMF messages across the trunk. Normalization Script: SIP trunks can connect to a variety of endpoints, including PBXs, gateways, and service providers. Each of these endpoints implements SIP a bit differently, causing a unique set of interoperability issues. To normalize messages per trunk, Cisco Unified Communications Manager allows you to add or update scripts to the system and then associate them with one or more SIP trunks. The normalization scripts that you create allow you to preserve, remove, or change the contents of any SIP headers or content bodies, known or unknown. In the example, the predefined vcs-interop script is used to provide interoperability for endpoints that are registered to a Cisco Video Communication Server (Cisco VCS) Cisco Systems, Inc. Implementing Advanced SIP Solutions 12-33

64 Configuring the Cluster Fully Qualified Domain Name The Cluster Fully Qualified Domain Name can be configured under enterprise parameters. Cisco Unified CM must be configured with a cluster fully qualified domain name so that it can receive calls to addresses in the format <address>@domain. Choose System > Enterprise parameters, and find the Clusterwide Domain Configuration section. Set the Cluster Fully Qualified Domain Name with the appropriate domain name of the Cisco Unified CM cluster. Click Save Cisco and/or its affiliates. All rights reserved. COLLAB90 v Use the following procedure to configure the Cluster Fully Qualified Domain Name: Step 1 Step 2 Step 3 Choose System > Enterprise Parameters and find the Clusterwide Domain Configuration section. Set the Cluster Fully Qualified Domain Name with the appropriate domain name of Unified CM cluster. Click Save Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

65 Configuring a Route Pattern to Route Calls to the SIP Trunk Device When the route pattern is matched, the call is forwarded to the associated SIP trunk. Choose Call Routing > Route/Hunt > Route Pattern. Click Add New. Configure a Route Pattern to route calls dialed 7XXX (in this example) to the SIP trunk. Set Pattern Definitions as shown: 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v Follow these steps to configure the route pattern to route calls to the SIP trunk: Step 1 Step 2 Step 3 Choose Call Routing > Route/Hunt > Route Pattern. Click Add New. Configure a Route Pattern representing the number or number range that should be reached by this route pattern (7XXX in the example). Set Pattern Definitions as follows: Route Pattern: 7XXX. Description: Enter a description for the route pattern. Gateway/Route List: Choose the SIP trunk pointing to the remote vendor. Call Classification: On-net. Provide Outside Dial Tone: Unchecked. (Usually, there is no need for an outside dial tone when the remote vendor is considered to be on-net.) 2013 Cisco Systems, Inc. Implementing Advanced SIP Solutions 12-35

66 Configuring a SIP Route Pattern to Route Calls with a Specified Domain Name To enable URI dialing, one or more SIP route patterns must exist. Configure a SIP route pattern that tells Cisco Unified CM, for example, that anything with a domain sip.domain.com needs to be sent down the remote vendor SIP trunk. Choose Call Routing > SIP Route Pattern. Click Add New. Configure a SIP Route Pattern as shown: 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v To enable URI dialing with the [email protected] format, SIP route patterns need to be configured. Configuration should be done as follows: Pattern Usage: Choose Domain Routing. IPv4 Pattern: This parameter depends on the domain that is being used in the environment. Route Partition: Choose a partition for the SIP route pattern. SIP Trunk/Route List: Choose the SIP trunk that points to the appropriate destination Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

67 Troubleshooting Advanced SIP Implementations This topic describes how to troubleshoot advanced SIP implementations. Description: When trying to create a conference from the remote vendor endpoint supporting Multiway, the Cisco Unified Communication Manager endpoints fail to join. Resolution: 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v Description When trying to create a conference from the remote endpoints that support Multiway, the Cisco Unified Communication Manager endpoints fail to join. Resolution Change the SIP profile as follows: Step 1 Choose Device > Device Settings > SIP Profile. Step 2 Step 3 Step 4 Find the SIP profile that is used for SIP IP phones. Check the Redirect by Application check box. Checking this check box allows the Cisco Unified Communications Manager system to process redirect messages on SIP devices using this profile. Click Apply Config and click OK Cisco Systems, Inc. Implementing Advanced SIP Solutions 12-37

68 Calls Clear Down When a Call Transfer from a Video Phone on Cisco Unified CM Transfers a Call via SIP Trunk Use of an MTP should always be avoided, if possible. Description: When transferring an ongoing video call via SIP trunk to a remote video device, the transfer is unsuccessful. Resolution: The DTMF signaling method must be configured according to RFC Cisco and/or its affiliates. All rights reserved. COLLAB90 v Description When transferring an ongoing video call via a SIP trunk to a remote video device, the transfer is not successful. Resolution Even if use of an MTP is not requested on the SIP trunk between Cisco Unified Communications Manager and targeting call control, if the DTMF signaling method is configured as No Preference on the SIP trunk on Cisco Unified Communications Manager, Cisco Unified Communications Manager will try to use an MTP and the call will fail. To resolve this issue, ensure that the DTMF signaling method is configured according to RFC 2833 on the Cisco Unified Communications Manager SIP trunk Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

69 IP Address Is Shown as Domain on Remote Endpoint This topic shows how to enable FQDN in SIP requests. Description: When the call is ringing on the endpoint that is connected through the SIP trunk, the IP address is shown as the domain. Resolution: Check the Use Fully Qualified Domain Name in SIP Requests check box in the SIP profile configuration Cisco and/or its affiliates. All rights reserved. COLLAB90 v Description When a call is ringing on an endpoint that is connected through the SIP trunk, the IP address is shown as the domain. Resolution To change the SIP profile, use the following procedure: Step 1 Choose Device > Device Settings > SIP Profile. Step 2 Step 3 Step 4 Find the SIP profile that is used for the SIP IP phone. Check the Use Fully Qualified Domain Name in SIP Requests check box. Click Save Cisco Systems, Inc. Implementing Advanced SIP Solutions 12-39

70 Summary This topic summarizes the key points that were discussed in this lesson. SIP creates, modifies, and terminates multimedia sessions with one or more participants. SDP describes session parameters in SIP message. Cisco Unified IP Phones 8961, 9951, and 9971 support MAC address registration. Enabling MTP on the SIP trunk will limit media to voice calls only. To enable joining to Multiway conference, you must enable Redirect by Application Cisco and/or its affiliates. All rights reserved. COLLAB90 v Cisco Unified Communications Manager offers a great set of features for SIP endpoints and for SIP trunks. Because of the wide support of SIP in the industry, using SIP is usually a good choice for connectivity to third-party applications and service providers. With video support, it provides interoperability with video endpoints that are registered to remote video call control Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

71 Appendix 13 Describing Call Routing Options and Priorities Overview Objectives This lesson provides an overview of call routing features in Cisco Unified Communications Manager version 9. The lesson describes call routing operations and provides a comparison of numeric versus alphanumeric dialing. The end of this lesson shows some call routing troubleshooting approaches. Upon completing this lesson, you will be able to describe call routing options and their priorities as well as troubleshoot call routing in Cisco Unified Communications Manager version 9. This ability includes being able to meet these objectives: Describe the call routing features in Cisco Unified Communications Manager version 9 Describe call routing operations Troubleshoot call routing

72 Overview of Call Routing Features in Cisco Unified Communications Manager Version 9 This topic describes call routing features. Call routing in Cisco Unified Communications Manager is based on the following procedures: Digit analysis - Dialing a digit string - Device dialing - Dialing methods Call routing - Which path will be chosen to take a call? 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v The digit analysis function controls the calls that are allowed to a user, to a gateway, or to an application. Call privileges, also known as classes of service (CoSs), are implemented in this function. The call routing function controls the path selection for a call. The call routing function chooses IP trunks, public switched telephone network (PSTN) trunks, or even connections to existing PBXs to carry a particular call. The call routing function also allows for the automated failover of calls from, for example, an IP connection as a first choice to a PSTN connection as a backup choice, if the first choice is not available because no bandwidth is available or because a particular portion of the network is not available Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

73 Digit Analysis: Dialing a Digit String When Cisco Unified Communications Manager performs digit analysis, some rules must be considered when dialing a digit string. A dialed string can consist of a number or URI address. Cisco Unified Communications Manager stores directory numbers and Directory URIs in distinct tables. Cisco Unified Communications Manager must differentiate between a directory number or directory URI that is being dialed. A dialed string contains user and host portions of the string that are separated by symbol. USER HOST [email protected] 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v All numeric dialing destinations and directory Uniform Resource Identifiers (URIs) that are configured in Cisco Unified Communications Manager are added to its internal call routing table as patterns. These destinations include IP phone lines, voic ports, route patterns, translation patterns, and computer telephony integration (CTI) route points. Cisco Unified Communications Manager uses two distinct routing tables for numeric dialing destinations and for directory URIs. All endpoints that are registered with Cisco Unified Communications Manager are provisioned with one or more numeric directory numbers, possibly including a leading plus sign (+). Starting with Cisco Unified Communications Manager version 9, up to five directory URIs can be associated with each directory number. This association is created by explicitly associating directory URIs to directory numbers. If a directory URI is configured for an end user, this directory URI will be automatically associated with the primary extension of this end user as soon as the primary extension is defined for this end user. All automatically associated directory URIs are created in the partition Directory URI, while manually configured directory URIs can be in any partition. Dialed strings contain a user and a host portion. The user portion can be alphanumeric. The host portion can contain an IP address or a hostname in alphabetical format Cisco Systems, Inc. Describing Call Routing Options and Priorities 13-3

74 Digit Analysis: Device Dialing A call can be initiated from multiple communication devices. Device IP phone Signaling Protocol SCCP SIP Addressing Method Digit by digit En bloc (Type-B phones only) En bloc KPML (Type-B phones only) SIP dial rules Dialed String DN DN DN and URI* DN DN Gateway Trunk MGCP, SIP, and H.323 SIP and H.323 En bloc Overlap sending and receiving (ISDN PRI only) En bloc Overlap sending and receiving DN DN DN and URI DN Directory URIs can be dialed from Cisco IP Phones 8961, 9951, and 9971 and Cisco Jabber for ipad. DN = Directory number 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v A call can be received from different device types and devices. Session Initiation Protocol (SIP) trunks can forward to outside or to inside numbers and directory URIs, while gateways can receive and send only directory numbers. To allow sending and receiving of directory URIs to and from a remote call control system, SIP route patterns must be configured. IP phones using the Skinny Client Control Protocol (SCCP) signaling protocol can receive calls to directory URIs. Type-B phones can display blended addressing and can send calls with directory URIs from speed-dial buttons. When using SIP as a protocol, only Cisco IP Phones 8961, 9951, and 9971 and Cisco Jabber for ipad can dial a directory URI Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

75 Digit Analysis: Dialing Methods There are different methods by which the target address can be dialed. IP phones have different addressing methods: Digit by digit (number only) En bloc (number or URI) Possible call sources: Manually entered dial strings Speed dials Directory entries Call history list 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v In Cisco Unified Communications Manager, the addressing methods determine what can be dialed. If digit-by-digit addressing is used, then only numbers can be dialed. In this method, each digit is sent in the signaling protocol to the call control server, and the digits are looked up in the call routing table as they are received. If the pattern is matched, then the call is forwarded to a target device. If there is no match, the call is rejected, even if the entire digit string is not entered yet. Only the call routing table that contains numbers is subject to the search. The directory URI table is not considered. When sending an entire dial string (en-bloc) to Cisco Unified Communications Manager, a number or a directory URI can be called. Not all devices support URI dialing. With URI dialing, the target address needs to be entered in the device. Then the dial button must be pressed to initiate an INVITE message. Calls can be initiated in different ways: Manually entered dial strings (entering a digit string in to the phone through the dial pad) Speed dials (Speed Dial buttons that are configured on Cisco Unified Communications Manager with a complete digit string) Directory entries (corporate or personal directory entries that are provisioned from the Lightweight Directory Access Protocol [LDAP] or statically entered) Call history list (list of missed, received, and placed calls) 2013 Cisco Systems, Inc. Describing Call Routing Options and Priorities 13-5

76 Call Routing Decisions For predictable routing of the dialed digit string, differentiation between a numeric and an alphanumeric string is mandatory. When routing SIP requests, Cisco Unified Communications Manager needs to determine whether the dialed string is a number or directory URI. Number Directory URI Calling CSS Best match from CSS partitions (priority order) Best match in SAF route patterns Best match in static route patterns No match Calling CSS Full match from CSS partitions (priority order) Full match in ILS Host match in SIP route pattern No match 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v Starting with Cisco Unified Communications Manager version 9, provisioning and dialing of alphanumeric directory URIs is supported. When managing SIP URIs, Cisco Unified Communications Manager needs to determine whether it is a numeric SIP URI or an alphanumeric SIP URI in order to look up the appropriate call routing table for a matching pattern. If a number is dialed, then the call processing server checks the table that contains numeric patterns. This table consists of statically configured entries such as directory numbers, route patterns, translation patterns, feature numbers like Meet-Me conferences or call park numbers, and numbers that are learned via the Service Advertisement Framework (SAF) Call Control Discovery (CCD) service. The order of partitions in the calling search space (CSS) of the calling device determines the priority of the partitions in case an equally qualified match is identified in more than one partition. Note All SAF- or CCD-learned patterns are assigned to the same partition. The administrator can configure the partition Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

77 If a directory URI is dialed, all of the rules for partitions and CSSs are the same as if a number is dialed. When a directory URI is dialed, the full match of the URI is matched against the URI patterns in the local table. If no directory URI is found locally in one of the accessible partitions, then the full URI is searched in the list of URIs that have been learned via the Intercluster Lookup Service (ILS). If found, a SIP route pattern for the route string that is associated with the matched pattern is searched for in all partitions of the CSS of the calling device. If the full URI is not found in the list of ILS URIs, then a SIP route pattern for the host portion of the initially called URI is searched for in all partitions of the calling device CSS. Note By default, the user portion of a directory URI is case-sensitive. This option can be changed using the enterprise parameter URI Lookup Policy Cisco Systems, Inc. Describing Call Routing Options and Priorities 13-7

78 Call Routing Operation This topic describes call routing scenarios for dialing directory numbers and directory URIs. Reminder: Is dial string a directory number? Yes No Does URI match one in URI table and CSS? Yes No Does URI match one in ILS? Yes No Does host portion match SIP route pattern? Yes No Block call Route as a directory number Offer call Route using SIP route patterns provided by ILS Route using matching SIP route pattern [email protected] User Portion of Directory URI Host Portion of Directory URI 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v Routing of SIP requests that are received from SIP trunks or SIP endpoints follows certain rules to make sure that both local and intercluster routing requirements are met. The figure shows a flowchart of routing decisions that are made by Cisco Unified Communications Manager. The first step is to check whether the user portion of the URI is a directory number or a directory URI. After identifying a SIP URI as being nonnumeric, the next step is to try to route the SIP request based on the CSS of the calling device. Cisco Unified Communications Manager searches for a full match of the SIP URI against all directory URIs that are configured in the partitions that are addressed by the calling device CSS. If a match is found, the call is extended to the directory number that is associated with the matched local directory URI. If no matching local directory URI is found, Cisco Unified Communications Manager tries to locate the SIP URI in imported directory URI catalogs or directory URI catalogs that are learned through ILS from remote systems, again by searching for a full match. In a match, the SIP request is routed by matching the SIP route string that is associated with the found directory URI against configured SIP route patterns. If the SIP URI does not match a local directory URI and also does not match any directory URI in any directory URI catalog, Cisco Unified Communications Manager then routes the SIP request based only on matching the right-hand side of the SIP URI against configured SIP route patterns. This final routing option can be used to create a default route for all SIP URIs that are not known locally or on any call control system that is connected through ILS Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

79 Reminder: Is host portion the IP address of local cluster member? Yes No Does host portion match CFQDN? Yes No Does host portion match OTLD? Yes No Match host portion against SIP route pattern Route or block Analyze user portion Does user portion find a match? No Yes Route or block Route or block 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v If a SIP URI is considered to be a numeric URI because the request included a user=phone tag or based on the originating device SIP profile dial string interpretation settings, the call is processed according to the flowchart that is shown in the figure. The first step is to check whether the host portion of the SIP URI is an IP address of any server that is a member of the Cisco Unified Communications Manager cluster or matches the cluster fully qualified domain name (CFQDN) that is configured in Cisco Unified Communications Manager enterprise parameters. In this case, the left-hand side of the URI is considered as a local directory number and will be routed as a number using the calling device CSS. The next step is to check whether the right-hand side of the SIP URI matches the organization top level domain (OTLD), which is configured in Cisco Unified Communications Manager enterprise parameters. If so, Cisco Unified Communications Manager will again try to route the call using the calling device CSS. If no match is 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. Assume a Cisco Unified Communications Manager cluster with cluster members having IP addresses , , , and Assume also that the CFQDN is configured as ucm1.cisco.com, and the OTLD is configured as cisco.com. Based on these assumptions, all of the following SIP URIs would be routed to the local directory number 1234: 1234@ @ @ @ @ucm1.cisco.com [email protected] 2013 Cisco Systems, Inc. Describing Call Routing Options and Priorities 13-9

80 Assuming that no local directory number 1234 exists, the first five calls would fail immediately. Cisco Unified Communications Manager would try to route the sixth call by matching cisco.com against the configured SIP route patterns Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

81 Digit-by-Digit Dialing This figure shows the digit-by-digit addressing method. Cisco IP Phone 9971 Cisco IP Phone ) Phone goes off-hook. URI: Directory Number: ) Dial 1, 0, 0, 1. URI: Directory Number: ) 1001 matches the directory number in the local cluster. 3) Blend the directory number for the calling party: ) Look up for "1001 " 5) Blend called party: "1001" 6) INVITE with Remote Party ID (RPID) 1000>. 7) 180 RINGING with RPID: 1001>. 7) RINGING. 8) Blend alerting ID: Cisco and/or its affiliates. All rights reserved. COLLAB90 v In this scenario, the user picks up the handset or presses the New Call button on the phone. Then the user presses 1, followed by 0, 0, and 1. Cisco Unified Communications Manager receives a SIP INVITE for each digit that is pressed. When the first SIP INVITE is received, Cisco Unified Communications Manager tries to match the dialed number to any pattern in the system. If there is only a partial match, Cisco Unified Communications Manager waits for additional digits. This procedure is repeated until a best match is found or an interdigit timeout occurs. When a best match is found, the call is extended to a target endpoint. If a digit-by-digit dialing method is used, only directory numbers can be dialed. If Cisco Unified Communications Manager receives a SIP INVITE with digits that do not match any pattern, the call will fail, even if this partial pattern could eventually be matched with a directory URI Cisco Systems, Inc. Describing Call Routing Options and Priorities 13-11

82 Cisco IP Phone 9971 Cisco IP Phone ) Phone goes off-hook. URI: Directory Number: ) Dial 2, 0, 0, URI: Directory Number: ) Digit 2 is matched for a partial or best match in Cisco Unified CM. 3) There is no pattern starting with a digit 2. 4) The call is rejected after pressing the first digit (2) Cisco and/or its affiliates. All rights reserved. COLLAB90 v Because Cisco Unified Communications Manager treats dialed digits as numbers, in the digitby-digit method, the 2001@ URI cannot be entered on the IP phone. In this scenario, the user is trying to dial 2001@ , but the call will fail by pressing the first digit (2). When a user presses the digit 2, Cisco Unified Communications Manager receives a SIP INVITE and checks the number pattern in the local table for a pattern starting with the digit 2. Because there is no pattern that is configured that starts with the digit 2, the user is not allowed to enter any additional digits, and the call is rejected Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

83 En Bloc Dialing In this scenario, the en bloc dialing method is explained. Cisco IP Phone 9971 Cisco IP Phone 9971 URI: Directory Number: ) User types 1001 or and presses Dial. URI: Directory Number: ) 1001 or matches the directory number in the local cluster. 3) Blend the directory number for the calling party: ) Look up for "1001" 5) Blend called party: "1001" 6) INVITE with Remote Party ID (RPID) 1000>. 7) 180 RINGING with RPID: 1001>. 7) RINGING. 8) Blend alerting ID: Cisco and/or its affiliates. All rights reserved. COLLAB90 v In the en bloc addressing method, the IP phone sends the SIP INVITE to the Cisco Unified Communications Manager when the Dial or Call button is pressed. The dialed string represents the entire digit string that is being entered into an IP phone, until the dial button is pressed. The Cisco Unified Communications Manager checks whether the user portion of the digit string is a number. In this case, the user portion is 1001 and is recognized as a number, so the call is always routed as a number and not as a URI address. For every call involving a directory number with an associated directory URI, Cisco Unified Communications Manager must decide which piece of the blended identity to use and to present to the endpoints or trunks that are involved in the call. This decision depends on the capabilities of the endpoints or trunks that are involved. Endpoints that register with Cisco Unified Communications Manager indicate during registration whether they are capable of processing directory URI-based caller IDs. For endpoints that indicate support of directory URIs during registration, Cisco Unified Communications Manager will always try to send directory URI-based caller IDs. Even if the call originated from a device that does not support directory URI dialing and caller ID, Cisco Unified Communications Manager can still use the primary directory URI of the calling directory number as a directory URI-based caller ID. In this case, the calling endpoint has an extension number 1000 and a directory URI that is configured as 2000@ When a call is extended to a target endpoint, the Cisco Unified Communications Manager sends the calling identity of 2000@ to the target endpoint. Cisco Unified Communications Manager checks the URI that is associated to a target device extension number and sends the called identity of 2001@ to a targeting endpoint. If the IP phone supports blended addressing, then the primary directory URI is shown on the IP phone. If not, the directory number is shown on the IP phone Cisco Systems, Inc. Describing Call Routing Options and Priorities 13-13

84 SIP INVITE Request with user=phone Parameter This figure shows how Cisco Unified Communications Manager manages the user=phone parameter in SIP requests. Cisco IP Phone 9971 Cisco IP Phone 9971 URI: Directory Number: ) User dials URI: Directory Number: ) Phone sends an INVITE with user=phone in the SIP request header: INVITE SIP/2.0 3) Even though the dial string matches the directory URI, the call will fail! Note: The user=phone will force Cisco Unified Communication Manager to treat the dialed string as a number Cisco and/or its affiliates. All rights reserved. COLLAB90 v In Cisco Unified Communications Manager version 9, the user=phone tag in a SIP request will force Cisco Unified Communications Manager to treat the SIP URI as a numeric URI. A SIP URI of the form [email protected];user=phone will never be routed successfully because the user=phone tag forces numeric treatment, and bob will not match any numeric pattern that is provisioned in Cisco Unified Communications Manager. In this scenario, a SIP URI is in the format 2001@ , and the Cisco Unified Communications Manager tries to find a numeric pattern by using the user portion of the SIP URI. There is no pattern with the directory number 2001, so the call will fail Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

85 Dial String Interpretation Dial string interpretation determines how the dialed digit string is processed. Cisco IP Phone 9971 Cisco IP Phone 9971 URI: Directory Number: ) User types 1001 or and presses Dial. URI: Directory Number: ) 1001 and is matched to a directory number in the local cluster. If Dial String Interpretation is configured as: Then the call to 1001@ will fail. If the user has configured SD (speed dial) with the "1001@ " directory URI, then: 1) When the user clicks on SD, 2) The phone sends an INVITE with abbrdial- number in the SIP request header. INVITE sip:x-cisco-serviceuri-abbrdial-1@ SIP/2.0 3) 1001@ is always routed as a directory URI, and the call FAILS! 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v Cisco Unified Communications Manager can be configured to treat a received dialed string differently. By default, the option Phone Number Consists of Characters 0-9, *, #, and + (Others Treated as URI Addresses) is configured on Cisco Unified Communications Manager. If the default option is set in the SIP profile for the calling phone, then the call to 1001 and 1001@ will be treated and routed as a directory number. The call will be successful when dialing either dial string. If the dial string interpretation is configured as Always Treat All Dial Strings as URI Addresses, then the call to 1001 will be successful, while the call to 1001@ will fail. Note When dialing a number only, the SIP INVITE contains the user=phone parameter, which forces Cisco Unified Communications Manager to treat the SIP URI as a numeric URI. When a speed dial is configured on Cisco Unified Communications Manager as a SIP URI address (1001@ ), the digit string is always treated as a URI address independently of dial string interpretation configuration. Because Cisco Unified Communications Manager does not have any URI address that is configured as 1001@ , the call would always fail when making a call by pressing a speed dial button Cisco Systems, Inc. Describing Call Routing Options and Priorities 13-15

86 Cisco IP Phone 9971 Cisco IP Phone 9971 URI: Directory Number: ) The user types and presses Dial. URI: Directory Number: ) is routed as a directory number (user side is a number) and is not matching any extension number. The call will FAIL! If the user has configured SD (Speed Dial) with the 2001@ " directory URI, then: 1) When the user clicks on SD, 2) The phone sends an INVITE with abbrdial- number in the SIP request header. INVITE sip:x-cisco-serviceuri-abbrdial-1@ SIP/2.0 3) 2001@ is routed as a directory URI. If the dial string interpretation is configured as: Then the call to 2001@ will fail Cisco and/or its affiliates. All rights reserved. COLLAB90 v When the default option for dial string interpretation is set, all URI addresses will be routed as directory numbers, if the user portion is a number. In this scenario, the user dials 2001@ and the call fails. The call is routed as a directory number and does not match any pattern in the Cisco Unified Communications Manager local table. Because all SIP URIs that are configured in a Speed Dial button are routed as directory URIs, the call is successful when triggered with a Speed Dial button. When the Dial String Interpretation parameter is set to Always Treat All Dial Strings as URI Addresses, then the call in this scenario is successful. Cisco Unified Communications Manager treats this dial string as a directory URI and checks the entire pattern in a directory URI table for a full match. Note The user=phone tag has priority over the Dial String Interpretation parameter Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

87 Routing a Directory URI with ILS This figure explains the call routing procedure when using ILS. [email protected] Learned from ILS [email protected] snj.route [email protected] tor.route 1 Bob calls [email protected]. routestring: snj.route 3 ILS Lookup leads to route string tor.route. ILS Exchange 2 Not routeable using Bob s CSS (not a local URI). 4 Call gets routed using SIP route pattern tor.route. Route string: tor.route 5 [email protected] is routeable using the trunk CSS (is a local URI). [email protected] 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v The figure shows an example of how a dialed directory URI is routed by Cisco Unified Communications Manager. In this example, the bottom Cisco Unified Communications Manager cluster advertises the local directory URI [email protected]. All local directory URIs of this Cisco Unified Communications Manager cluster are advertised with the SIP route string tor.route. As part of this information exchange over ILS, the Cisco Unified Communications Manager cluster at the top populated its local directory URI catalog with the association of [email protected] to the SIP route string tor.route. If someone then places a call from the phone that is registered in the top cluster to directory URI [email protected], the local lookup of directory URI [email protected] will fail because [email protected] is not a local directory URI. The next step in the routing process is to search for [email protected] in the table of directory URIs that are learned through ILS. This search will match the entry that is learned from the bottom cluster. The originating cluster at the top then uses the SIP route string that is associated with the URI (tor.route) and tries to find a route by matching the SIP route string tor.route against the configured SIP route patterns. A SIP route pattern tor.route is configured and points to a route list that ultimately leads to the SIP trunk that points to the target Cisco Unified Communications Manager cluster. The originating Cisco Unified Communications Manager cluster thus routes the call to the destination Cisco Unified Communications Manager cluster. The destination in the sent SIP request will be [email protected]. The route string is not passed onto the destination cluster. It was only significant to the call routing decision at the originating cluster. On the destination cluster, the same routing logic then tries to match [email protected] against all local directory URIs, which leads to a full match and the target device rings. This example shows that the SIP route string namespace is completely independent of the directory URI namespace. There is no requirement to use SIP route strings that are related in any way to the structure of the namespace that is used for the host portion of directory URIs Cisco Systems, Inc. Describing Call Routing Options and Priorities 13-17

88 This situation allows the SIP route string namespace to be optimized based on the desired routing topology. To disambiguate between SIP route patterns that are used to directly match on the URI host portion and SIP route patterns that are used to route directory URIs based on SIP route strings, it is highly recommended that you use an independent namespace for the SIP route string route patterns (for example, route or.ils) Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

89 Call Routing Troubleshooting This topic describes how to troubleshoot call routing in Cisco Unified Communications Manager. Cisco IP Phone 9971 Cisco IP Phone ) User dials URI: [Directory URI] Directory Number: 1000 [None] CSS: [None] 2) SIP INVITE is sent to the Unified CM. URI: [Directory URI] Directory Number: 1001 [None] CSS: [None] 3) 100 Trying is returned. 4) 183 Session Progress message is forwarded to the targeting endpoint, denying the call with the reason "security= NotAuthenticated." 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v In the figure, the user is trying to dial which is a directory URI address that is provisioned via LDAP and associated with directory number The call fails with an error called security=notauthenticated. This error occurs when the user does not have sufficient privileges to call the target endpoint. Note LDAP-provisioned URI addresses are automatically added to a default partition called Directory URI. To resolve this issue, a CSS must be configured on the calling endpoint. This CSS must contain the partition called Directory URI, where the [email protected] URI is located Cisco Systems, Inc. Describing Call Routing Options and Priorities 13-19

90 Directory URI on Remote Cluster Is Inaccessible In this example, the target endpoint, which is located on a remote cluster, cannot be accessed. Cisco IP Phone 9971 Cisco IP Phone ) User dials [email protected]. URI: [email protected] [B] Directory Number: 1000 [B] CSS: Partition A, B URI: [email protected] [B] Directory Number: 1001 [B] SIP Route Pattern: CSS: [None] Domain: cisco.com Partition: A SIP Trunk: toremotecucm SIP Trunk: Incoming Partition: C URI: [email protected] [C] Directory Number: 1001 [C] CSS: [None] Cisco IP Phone Cisco and/or its affiliates. All rights reserved. COLLAB90 v In this scenario, the URI [email protected] exists twice in two different clusters. When [email protected] is called from the phone with directory number 1000, the call is extended to [email protected] in the local Cisco Unified Communications Manager cluster. The calling user CSS is configured to prioritize the A partition, where a SIP route pattern is configured with a cisco.com domain, pointing to a remote cluster via a SIP trunk. Nevertheless, the local URI is preferred. The local URI is preferred because if the URI address is found in a local cluster with a partition from the calling endpoint CSS, then the call is extended to the locally configured directory URI. If there is no full match in any partition from the calling CSS locally, then Cisco Unified Communications Manager checks the ILS and SIP route patterns for a match in all partitions from the calling CSS (top-down priority) Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.

91 Dialing the User Portion of a Directory URI Is Disabled This figure shows a scenario in which only the user portion of the SIP URI cannot be called. = = 2013 Cisco and/or its affiliates. All rights reserved. COLLAB90 v In this example, the user cannot dial the user portion of the directory URI only. The Call button is grayed out and cannot be pressed. This scenario will happen when the OTLD is not configured with a domain name of the local Cisco Unified Communications Manager cluster. To resolve this issue, set the Organization Top Level Domain parameter with an appropriate domain name and restart all devices Cisco Systems, Inc. Describing Call Routing Options and Priorities 13-21

92 Summary This topic summarizes the key points that were discussed in this lesson. When routing SIP requests, Cisco Unified Communications Manager needs to determine if the dialed string is a number or directory URI. The user=phone tag in a SIP request will force Cisco Unified Communications Manager to treat the SIP URI as a numeric URI. The SIP URI address is primarily checked in the local table against partitions in the calling CSS. If there is no match, the URI is checked with ILS and the SIP route pattern Cisco and/or its affiliates. All rights reserved. COLLAB90 v References This lesson described different methods of dialing numeric and alphanumeric dial strings. The lesson explained numerous scenarios when dialing manually entered digit strings and when using speed dials to trigger calls. For additional information, refer to this resource: Cisco Systems, Inc., Cisco Collaboration 9.x Solution Reference Network Designs (SRND), Dial Plan section at: Appendix Collaboration 9.0 Features 2013 Cisco Systems, Inc.