Implementing Intercluster Lookup Service

(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

(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

emea.cisco.com amer.cisco.com

[email protected] [email protected]

[email protected]

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.

(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.

• No cluster identification is possible.

• Calls to remote destinations will fail.

[email protected] [email protected]

[email protected]

?

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.

(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 theURI host portion but on a learned route string.

• This allows the sameURI host portion (domain) to be used at multiple clusters.

[email protected] route string: [email protected]

amer.cisco.com route string: emea.cisco.com [email protected] -> emea.cisco.com [email protected] -> amer.cisco.com

ILS URI exchange:

emea.cisco.com amer.cisco.com

SIP route patterns:

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 enterprise-wide 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.

(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.

(6)

Main ILS Components

This section lists and describes the main components of ILS.

Component Description

ILS Networking Joins clusters into a network. Provides

discovery of ILS services available on remote clusters.

URI Syncing 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.

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.

(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.

Full Mesh of Three Hub Clusters Hub1, One Spoke Hub2, Two Spokes Hub3, No Spokes Spoke1 Spoke2 Spoke3

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.

(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).

Hub1 Hub2

Spoke1 Spoke2

Spoke1 Pull Hub1 Pull Hub2 Pull

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.

(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 Hub2 Hub3 Spoke1 Spoke2 Spoke3

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.

(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:

Yes No Yes No _Block call. Yes No No Yes Yes No Is user portion of URI a DN? Route as a DN.

Does URI match an entry in any accessible partition of local URI table? Offer call. Does host portion of URI match a SIP route pattern in any accessible partition? Route using matching SIP route pattern. Does URI match

any learned ILS URI?

Does route string of matched ILS URI match a SIP

route pattern in any accessible

partition?

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.

(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.

(12)

URI Import and Export

This section describes the option to import and export URIs into Cisco Unified Communications Manager.

• 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.

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.

(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 [email protected] calls [email protected], 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.

[email protected] Route String: [email protected]

amer.cisco.com Route String: emea.cisco.com [email protected] -> emea.cisco.com [email protected] -> amer.cisco.com

ILS URI Syncing:

ILS-Learned URIs: [email protected] -> amer.cisco.com

ILS-Learned URIs: [email protected] -> emea.cisco.com

emea.cisco.com

SIP Route Patterns:

amer.cisco.com

SIP Route Patterns:

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 [email protected] calls [email protected], the following URI routing process occurs:

Step 1 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.

Step 2 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.

(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.

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.

(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.

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.

(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 SME ILS Hub Leaf3 ILS Spoke Leaf2 ILS Spoke Leaf4 ILS Spoke

SIP Route Pattern: * -> SME-ICT SIP Trunk: SME-ICT -> SME

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: l1.cisco.com Route String: l3.cisco.com Route String: l4.cisco.com 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

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.

(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.

This section illustrates the ILS networking configuration procedure, which consists of the following steps:

Step 1 Configure a globally unique enterprise cluster ID.

Step 2 Configure membership of an ILS network:

 Configure the first hub.

 Configure additional hubs.

 Configure spokes.

Step 3 Exchange Tomcat certificates of all potential xnodes (optional).

Step 4 Configure the synchronization interval.

(18)

Step 1: Configure the Cluster ID

The figure shows the configuration of the cluster ID.

(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.

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.

(20)

Step 2b: Configure an Additional Hub

This section describes how to add an additional ILS hub cluster to the ILS network.

Cluster, the registration server must be entered.

Enter the IP address of the first hub cluster server running ILS.

Additional ILS hub clusters are added to an existing ILS network as follows:

 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.

(21)

Step 2c: Configure a Spoke

This section describes how to add an ILS spoke cluster to the ILS network.

Enter the IP address of the hub cluster server running ILS.

ILS spoke clusters are added to an existing ILS network as follows:

 Choose the ILS authentication method (certificate or password).

(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.

(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).

At the ILS Configuration page, you can change the synchronization interval. The default is 10 minutes.

(24)

Step 5: Verify ILS Networking Using Cluster View

This section shows how to verify ILS networking configuration and operation.

Select the remote cluster.

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

(25)

ILS-Based URI Routing Configuration Procedure

This section describes how to configure ILS-based URI routing.

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.

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 Enable URI syncing via ILS.

(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.

Set the route string.

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.

(27)

ILS Monitoring

This topic describes how to monitor ILS operation.

Command Description

utils ils

findroutestring

uri

Displays all route strings that are associated with the specified URI.

utils ils lookup

uri

Displays the route string that is used to route a call to the specified URI.

utils ils findxnode

Displays the current xnode of the local cluster.

utils ils showpeerinfo

Displays information such as the route string, enterprise cluster ID, and role (hub versus spoke) about ILS peers.

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.

(28)

ILS Alarms

This section lists and describes the alarms that are available to monitor ILS.

• TLSAuthenticationFailed • TCPInUse • TCPListenError • ILSHubClusterUnreachable • ILSRemoteHostUnresponsive • ILSProtocolVersion • ILSUnacceptableConnectionAttempt • ILSDuplicateURIOnLookup • ILSDuplicateURIOnReplication

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.

(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.

(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.

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.

References

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:

(31)

Appendix 12

Implementing Advanced SIP

Solutions

Overview

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.

Objectives

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

(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

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).

(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

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

(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

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.

(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] 2. INVITE (SDP) [email protected] 3. 100 Trying 4. 180 Ringing 4. 180 Ringing 5. 200 OK 5. 200 OK AUDIO VIDEO 6. ACK 6. ACK 8. BYE 8. BYE 9. 200 OK 9. 200 OK 7. Media (UTP)

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 The Cisco Unified Communications Manager forwards this invitation to the targeting endpoint.

Step 3 The originating endpoint receives a 100 Trying message from Cisco Unified Communications Manager, which indicates that the INVITE was sent to the targeting endpoint.

Step 4 The terminating endpoint sends the ringing signal to the originating endpoint.

(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

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

(37)

Example:

• Audio, RTP/49174, G.711 mu-law • Video, RTP/49170, H261 v=0

o=bob 15553032001 IN IP4 host1.cisco.com s=Example c=IN IP4 10.1.1.1 t=0 0 m=audio 49174 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 49170 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

name

s=<session name>

Connection data

c=<network type> <address type> <connection address>

Times t=<start time> <stop time> Media m=<media> <port> <transport>

<media format list> Audio Video Profile (AVP) codes 0: G.711 mu-law 8: G.711 a-law 3: GSM codec 18: G.729 31: H261

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).

(38)

Delayed Offer

Delayed offer is one method of negotiating media.

1. INVITE [email protected]

2. INVITE [email protected] 3. 100 Trying

4. 180 Ringing 4. 180 Ringing

5. 200 OK (SDP: Media Offer) 5. 200 OK (SDP: Media Offer)

AUDIO VIDEO

6. ACK (SDP: Media Answer) 6. ACK (SDP: Media Answer)

7. BYE 7. BYE

8. 200 OK 8. 200 OK

Media (UTP)

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.

(39)

Early Offer

The INVITE message contains the SDP media offer when the call is initialized.

1. INVITE (SDP: Media Offer)

2. INVITE (SDP: Media Offer) 3. 100 Trying

4. 180 Ringing 4. 180 Ringing

5. 200 OK (SDP: Media Answer) 5. 200 OK (SDP: Media Answer)

AUDIO VIDEO 6. ACK 6. ACK 7. BYE 7. BYE 8. 200 OK 8. 200 OK Media (UTP)

(40)

Early Media

Sending of media can be allowed before the call is accepted.

183 Session Progress Option

1. INVITE

2. INVITE 3. 100 Trying

4. 183 Session Progress (SDP: MO) 4. 183 Session Progress (SDP: Media Offer) 5. Pre-ACK (SDP: Media Response) 5. Pre-ACK (SDP: Media Response)

AUDIO VIDEO 6. 180 Ringing 6. 180 Ringing 7. 200 OK 7. 200 OK 8. ACK 8. ACK Media (UTP)

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.

(41)

180 Ringing Option 1. INVITE

2. INVITE 3. 100 Trying

4. 180 Ringing (SDP: Media Offer) 4. 180 Ringing (SDP: Media Offer) 5. Pre-ACK (SDP: Media Response) 5. Pre-ACK (SDP: Media Response)

AUDIO VIDEO

7. 200 OK 7. 200 OK

8. ACK 8. ACK

Media (UTP)

(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.

PRI Gateway TDM MTP 1 2 3 SIP IP Phone RTP Stream RTP Stream PSTN

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

(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 7975.

• Cisco Unified IP phones with SIP-only support:

- Cisco Unified IP Phones 8961, 9951, and 9971.

• Third-party IP phones support limited features when registered to Cisco Unified Communications Manager.

• Blended addressing is not supported with Type-A IP phones.

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.

(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

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

(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

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:

http://www.cisco.com/en/US/products/ps10451/index.html

 Cisco Unified IP Phone 9900 Series:

(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)

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.

(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.

Perform the following steps to configure the phone security profile:

Step 1 Choose System > Security > Phone Security Profile.

Step 2 Find the security profile that contains the IP phone model number in the name field.

Step 3 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 Depending on the chosen phone model, the phone security profile will only include the configuration parameter that is applicable to the chosen phone.

(48)

Device Security Modes:

• Non Secure

• Authenticated

• Encrypted

Transport Types in Non Secure Mode:

• TCP

• UDP

• TCP+UDP

Transport Types in Secure Mode:

• TLS

Enable IP phone configuration encryption by checking this box. To enable Digest Authentication, check this box.

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

(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.

(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.

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.

(51)

• When the SIP device is a tablet device, the following parameters should be changed:

- Timer Register Delta (seconds): 60

- Timer Register Expires (seconds):

660

- Timer Keep Alive Expires (seconds):

660

- Timer Subscribe Expires (seconds):

660

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 Choose Device > Device Settings > SIP Profile.

Step 2 Create a SIP profile or copy an existing SIP profile. You can name the profile Standard Tablet SIP Profile.

Step 3 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)

(52)

SIP Multivendor Implementation Considerations

This topic describes how to implement Cisco Unified Communications Manager with multiple vendors via SIP.

Cisco VCS

SIP Proxy SIP Trunk

SIP IP Phone

SIP Video Phone

SIP Video TelePresence SIP Video TelePresence TelePresence Endpoint with Twin Data Display Third-Party Class 4/5 Switch Internet Telephony Service Provider

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.

(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.

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 Configure your region with an appropriate session bit rate for video calls, if applicable.

Step 2 Configure a SIP profile for phone devices.

Step 3 Add SIP IP phone devices.

Step 4 Configure the device directory number: specify the telephone number that will cause this phone to ring.

Step 5 Configure the SIP trunk security profile.

(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).

Ensure that your region has an appropriate session bit rate for video calls:

Step 1 Choose System > Region Information > Region.

Step 2 Choose the region (for example, the Default region).

Step 3 Set the Maximum Session Bit Rate for Video Calls to a suitable upper limit (for example, 6000 kb/s).

(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 Standard SIP Profile – for SIP phones

Use Fully Qualified Domain in SIP

Requests Check the check box.

Allow Presentation Sharing Using BFCP

Check the check box if BFCP (dual video and presentation sharing) is required.

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 Choose Device > Device Settings > SIP Profile.

Step 2 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.

(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.

Use the following procedure to add a phone device:

Step 1 Choose Device > Phone.

Step 2 Click Add New.

Step 3 Choose Standard SIP Profile – for SIP phones in the SIP profile drop-down list.

Step 4 Configure the other fields as required, such as MAC address, description, and so on.

Step 5 Click Save and click OK.

Step 6 Click Apply Config and click OK.

(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.

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.