Cisco Jabber 10.6 Planning Guide

Cisco Jabber 10.6 Planning Guide

C H A P T E R

8

Planning Considerations

DNS Configuration, page 59

How the Client Connects to Services, page 69

High Availability, page 74

Computer Telephony Integration, page 76

DNS Configuration

How the Client Uses DNS

Cisco Jabber uses domain name servers to do the following:

• Determine whether the client is inside or outside the corporate network.

• Automatically discover on-premises servers inside the corporate network.

• Locate access points for Expressway for Mobile and Remote Access on the public Internet.

How the Client Finds a Name Server

Cisco Jabber looks for DNS records from:

• Internal name servers inside the corporate network.

• External name servers on the public Internet.

When the client’s host computer or device gets a network connection, the host computer or device also gets the address of a DNS name server from the DHCP settings. Depending on the network connection, that name server might be internal or external to the corporate network.

Cisco Jabber queries the name server that the host computer or device gets from the DHCP settings.

Cisco Jabber 10.6 Planning Guide

59

Planning Considerations

How the Client Uses DNS

How the Client Gets a Services Domain

The services domain is discovered by the Cisco Jabber client in different ways.

New installation:

• User enters an address in the format [email protected]

in the client user interface.

• User clicks on a configuration URL that includes the service domain. This option is only available in the following versions of the client:

• Cisco Jabber for Android release 9.6 or later

• Cisco Jabber for Mac release 9.6 or later

• Cisco Jabber for iPhone and iPad release 9.6.1 or later

• The client uses installation switches in bootstrap files. This option is only available in the following version of the client:

◦Cisco Jabber for Windows release 9.6 or later

Existing installation:

• The client uses the cached configuration.

• User manually enters an address in the client user interface.

In hybrid deployments the domain required to discover Cisco WebEx domain through Central Authentication

Service (CAS) lookup may be different to the domain where the DNS records are deployed. In this scenario you set the ServicesDomain to be the domain used to discover Cisco WebEx and set the VoiceServicesDomain to be the domain where DNS records are deployed. The voice services domain is configured as follows:

• The client uses the VoiceServicesDomain parameter in the configuration file. This option is available in clients that support the jabber-config.xml file.

• User clicks on a configuration URL that includes the VoiceServicesDomain. This option is available in the following clients:

◦Cisco Jabber for Android release 9.6 or later

◦Cisco Jabber for Mac release 9.6 or later

◦Cisco Jabber for iPhone and iPad release 9.6.1 or later

• The client uses the Voice_Services_Domain installation switch in the bootstrap files. This option is only available in the following version of the client:

◦Cisco Jabber for Windows release 9.6 or later

After Cisco Jabber gets the services domain, it queries the name server that is configured to the client computer or device.

60

Cisco Jabber 10.6 Planning Guide

Planning Considerations

How the Client Discovers Available Services

The following figure shows the flow that the client uses to connect to services.

Figure 9: Login Flow for Service Discovery

How the Client Uses DNS

To discover available services, the client does the following:

1

Checks if the network is inside or outside the firewall and if Expressway for Mobile and Remote Access is deployed. The client sends a query to the name server to get DNS Service (SRV) records.

2

Starts monitoring for network changes.

When Expressway for Mobile and Remote Access is deployed, the client monitors the network to ensure that it can reconnect if the network changes from inside or outside the firewall.

3

Issues an HTTP query to a CAS URL for the Cisco WebEx Messenger service.

This query enables the client to determine if the domain is a valid Cisco WebEx domain.

When Expressway for Mobile and Remote Access is deployed, the client connects to Cisco WebEx

Messenger Service and uses Expressway for Mobile and Remote Access to connect to Cisco Unified

Cisco Jabber 10.6 Planning Guide

61

Planning Considerations

How the Client Uses DNS

Communications Manager. When the client launches for the first time the user will see a Phone Services

Connection Error and will have to enter their credentials in the client options screen, subsequent launches will use the cached information.

4

Queries the name server to get DNS Service (SRV) records, unless the records exist in the cache from a previous query.

This query enables the client to do the following:

• Determine which services are available.

• Determine if it can connect to the corporate network through Expressway for Mobile and Remote

Access.

Client Issues an HTTP Query

In addition to querying the name server for SRV records to locate available services, Cisco Jabber sends an

HTTP query to the CAS URL for the Cisco WebEx Messenger service. This request enables the client to determine cloud-based deployments and authenticate users to the Cisco WebEx Messenger service.

When the client gets a services domain from the user, it appends that domain to the following HTTP query: http://loginp.webexconnect.com/cas/FederatedSSO?org=

For example, if the client gets example.com as the services domain from the user, it issues the following query: http://loginp.webexconnect.com/cas/FederatedSSO?org=example.com

That query returns an XML response that the client uses to determine if the services domain is a valid Cisco

WebEx domain.

If the client determines the services domain is a valid Cisco WebEx domain, it prompts users to enter their

Cisco WebEx credentials. The client then authenticates to the Cisco WebEx Messenger service and retrieves the configuration and UC services that are configured in Cisco WebEx Org Admin.

If the client determines the services domain is not a valid Cisco WebEx domain, it uses the results of the query to the name server to locate available services.

When the client sends the HTTP request to the CAS URL, it uses configured system proxies.

For the desktop clients, to configure a proxy in the LAN Settings of Internet Explorer, you must specify a

.pac

file URL as the automatic configuration script or specify an explicit proxy address under Proxy server.

For iOS clients, you can configure a proxy in the Wi-Fi settings of an iOS device, using one of the following methods:

1

Go to Wi-Fi > HTTP PROXY > Auto tab and use Web Proxy Auto-Discovery (WPAD) protocol lookup.

Do not specify .pac file URL.

2

Specify a.pac file URL as the automatic configuration script in Wi-Fi > HTTP PROXY > Auto tab.

3

Specify an explicit proxy address in Wi-Fi > HTTP PROXY > Manual tab.

For Android clients, you can configure a proxy in the Wi-Fi settings of a Android device using one of the following methods:

1

Specify a.pac file URL as the automatic configuration script in Wi-Fi Networks > Modify Network

> Show Advanced Options > Proxy Settings > Auto tab.

62

Cisco Jabber 10.6 Planning Guide

Planning Considerations

How the Client Uses DNS

Note

This method is only supported on devices with Android OS 5.0 and higher, and Cisco DX series devices.

2

Specify an explicit proxy address in Wi-Fi Networks > Modify Network > Show Advanced Options

> Proxy Settings > Auto tab.

The following limitations apply when using a proxy for these HTTP requests:

• Proxy Authentication is not supported.

• Wildcards in the bypass list are not supported. Use example.com instead of *.example.com.

• Web Proxy Auto-Discovery (WPAD) protocol lookup is only supported for iOS devices.

• Cisco Jabber supports proxy for HTTP request using HTTP CONNECT, but does not support proxy when using HTTPS CONNECT.

Client Queries the Name Server

When the client queries a name server, it sends separate, simultaneous requests to the name server for SRV records.

The client requests the following SRV records in the following order:

• _cisco-uds

• _cuplogin

• _collab-edge

If the name server returns:

• _cisco-uds—The client detects it is inside the corporate network and connects to Cisco Unified

Communications Manager.

• _cuplogin—The client detects it is inside the corporate network and connects to Cisco Unified

Presence.

• _collab-edge—The client attempts to connect to the internal network through Expressway for

Mobile and Remote Access and discover services

• None of the SRV records—The client prompts users to manually enter setup and sign-in details.

Cisco Jabber 10.6 Planning Guide

63

How the Client Uses DNS

Client Connects to Internal Services

The following figure shows how the client connects to internal services:

Figure 10: Client Connecting to Internal Services

Planning Considerations

When connecting to internal services, the goals are to determine the authenticator, sign users in, and connect to available services.

Three possible authenticators can get users past the sign-in screen, as follows:

• Cisco WebEx Messenger service—Cloud-based or hybrid cloud-based deployments.

• Cisco Unified Presence—On-premises deployments in the default product mode. The default product mode can be either full UC or IM only.

• Cisco Unified Communications Manager—On-premises deployments in phone mode.

The client connects to any services it discovers, which varies depending on the deployment.

1

If the client discovers that the CAS URL lookup indicates a Cisco WebEx user, the client does the following:

a

Determines that the Cisco WebEx Messenger service is the primary source of authentication.

b

Automatically connects to the Cisco WebEx Messenger service.

c

Prompts the user for credentials.

d

Retrieves client and service configuration.

64

Cisco Jabber 10.6 Planning Guide

Planning Considerations

How the Client Uses DNS

2

If the client discovers a

_cisco-uds

SRV record, the client does the following:

1

Prompts the user for credentials to authenticate with Cisco Unified Communications Manager.

2

Locates the user's home cluster.

Locating the home cluster enables the client to automatically get the user's device list and register with

Cisco Unified Communications Manager.

Important

In an environment with multiple Cisco Unified Communications Manager clusters, you must configure the Intercluster Lookup Service (ILS). ILS enables the client to find the user's home cluster.

See the appropriate version of the Cisco Unified Communications Manager Features and Services Guide to learn how to configure ILS.

3

Retrieves the service profile.

The service profile provides the client with the authenticator as well as client and UC service configuration.

The client determines the authenticator from the value of the Product type field in the IM and presence profile, as follows:

• Cisco Unified Communications Manager —Cisco Unified Presence or Cisco Unified

Communications Manager IM and Presence Service is the authenticator.

• WebEx (IM and Presence)—Cisco WebEx Messenger service is the authenticator.

Note

As of this release, the client issues an HTTP query in addition to the query for SRV records. The HTTP query allows the client to determine if it should authenticate to the

Cisco WebEx Messenger service.

As a result of the HTTP query, the client connects to the Cisco WebEx Messenger service in cloud-based deployments. Setting the value of the Product type field to

WebEx does not effect if the client has already discovered the WebEx service using a

CAS lookup.

• Not set—If the service profile does not contain an IM and Presence Service configuration, the authenticator is Cisco Unified Communications Manager.

4

Sign in to the authenticator.

After the client signs in, it can determine the product mode.

3

If the client discovers a _cuplogin SRV record, the client does the following:

1

Determines that Cisco Unified Presence is the primary source of authentication.

2

Automatically connects to the server.

3

Prompts the user for credentials.

4

Retrieves client and service configuration.

Cisco Jabber 10.6 Planning Guide

65

Planning Considerations

Domain Name System Designs

Client Connects through Expressway for Mobile and Remote Access

If the name server returns the _collab-edge SRV record, the client attempts to connect to internal servers through Expressway for Mobile and Remote Access.

The following figure shows how the client connects to internal services when the client is connected to the network through Expressway for Mobile and Remote Access:

Figure 11: Client Connects through Expressway for Mobile and Remote Access

When the name server returns the _collab-edge SRV record, the client gets the location of the Cisco

Expressway-E server. The Cisco Expressway-E server then provides the client with the results of the query to the internal name server.

Note

The Cisco Expressway-C server looks up the internal SRV records and provides the records to the Cisco

Expressway-E server.

After the client gets the internal SRV records, which must include the _cisco-udsSRV record, it retrieves service profiles from Cisco Unified Communications Manager. The service profiles then provide the client with the user's home cluster, the primary source of authentication, and configuration.

Domain Name System Designs

Where you deploy DNS service (SRV) records depends on the design of your DNS namespace. Typically there are two DNS designs:

• Separate domain names outside and inside the corporate network.

66

Cisco Jabber 10.6 Planning Guide

Planning Considerations

• Same domain name outside and inside the corporate network.

Separate Domain Design

The following figure shows a separate domain design:

Figure 12: Separate Domain Design

Domain Name System Designs

An example of a separate domain design is one where your organization registers the following external domain with an Internet name authority: example.com.

Your company also uses an internal domain that is one of the following:

• A subdomain of the external domain, for example, example.local.

• A different domain to the external domain, for example, exampledomain.com.

Separate domain designs have the following characteristics:

• The internal name server has zones that contain resource records for internal domains. The internal name server is authoritative for the internal domains.

• The internal name server forwards requests to the external name server when a DNS client queries for external domains.

• The external name server has a zone that contains resource records for your organization’s external domain. The external name server is authoritative for that domain.

• The external name server can forward requests to other external name servers. However, the external name server cannot forward requests to the internal name server.

Deploy SRV Records in a Separate Domain Structure

In a separate name design there are two domains, an internal domain and an external domain. The client queries for SRV records in the services domain. The internal name server must serve records for the services domain. However in a separate name design, a zone for the services domain might not exist on the internal name server.

If the services domain is not currently served by the internal name server, you can:

• Deploy records within an internal zone for the services domain.

• Deploy records within a pinpoint subdomain zone on the internal name server.

Cisco Jabber 10.6 Planning Guide

67

Planning Considerations

Domain Name System Designs

Use an Internal Zone for a Services Domain

If you do not already have a zone for the services domain on the internal name server, you can create one.

This method makes the internal name server authoritative for the services domain. Because it is authoritative, the internal name server does not forward queries to any other name server.

This method changes the forwarding relationship for the entire domain and has the potential to disrupt your internal DNS structure. If you cannot create an internal zone for the services domain, you can create a pinpoint subdomain zone on the internal name server.

Same Domain Design

An example of a same domain design is one where your organization registers example.com as an external domain with an Internet name authority. Your organization also uses example.com as the name of the internal domain.

Single Domain, Split-Brain

The following figure shows a single domain with a split-brain domain design.

Figure 13: Single Domain, Split-Brain

Two DNS zones represent the single domain; one DNS zone in the internal name server and one DNS zone in the external name server.

Both the internal name server and the external name server are authoritative for the single domain but serve different communities of hosts.

• Hosts inside the corporate network access only the internal name server.

• Hosts on the public Internet access only the external name server.

• Hosts that move between the corporate network and the public Internet access different name servers at different times.

68

Cisco Jabber 10.6 Planning Guide

Planning Considerations

How the Client Connects to Services

Single Domain, Not Split-Brain

The following figure shows a single domain that does not have a split-brain domain design.

Figure 14: Single Domain, Not Split-Brain

In the single domain, not split-brain design, internal and external hosts are served by one set of name servers and can access the same DNS information.

Important

This design is not common because it exposes more information about the internal network to potential attackers.

How the Client Connects to Services

To connect to services, Cisco Jabber requires the following information:

• Source of authentication that enables users to sign in to the client.

• Location of services.

You can provide that information to the client with the following methods:

URL Configuration

Users are sent an email from their administrators. The email contains a URL that will configure the domain needed for service discovery.

Service Discovery

The client automatically locates and connects to services.

Manual Connection Settings

Users manually enter connection settings in the client user interface.

Cisco Jabber 10.6 Planning Guide

69

Planning Considerations

Recommended Connection Methods

Recommended Connection Methods

The method that you should use to provide the client with the information it needs to connect to services depends on your deployment type, server versions, and product modes. The following tables highlight various deployment methods and how to provide the client with the necessary information.

Table 2: On-Premises Deployments for Cisco Jabber for Windows

Product

Mode

Full UC

(default mode)

Server Versions

Release 9.1.2 and later:

• Cisco Unified

Communications

Manager

• Cisco Unified

Communications

Manager IM and

Presence Service

Discovery Method Non DNS SRV Record Method

A DNS SRV request against

_cisco-uds .<domain>

Use the following installer switches and values:

• AUTHENTICATOR=CUP

• CUP_ADDRESS=

<presence_server_address>

Full UC

(default mode)

Release 8.x:

• Cisco Unified

Communications

Manager

• Cisco Unified

Presence

IM Only

(default mode)

Release 9 and later:

Cisco Unified

Communications

Manager IM and

Presence Service

A DNS SRV request against

_cuplogin.<domain>

Use the following installer switches and values:

• AUTHENTICATOR=CUP

• CUP_ADDRESS=

<presence_server_address>

A DNS SRV request against

_cisco-uds .<domain>

Use the following installer switches and values:

• AUTHENTICATOR=CUP

• CUP_ADDRESS=

<presence_server_address>

IM Only

(default mode)

Release 8.x:

Cisco Unified Presence

A DNS SRV request against

_cuplogin .<domain>

Use the following installer switches and values:

• AUTHENTICATOR=CUP

• CUP_ADDRESS=

<presence_server_address>

70

Cisco Jabber 10.6 Planning Guide

Planning Considerations

Recommended Connection Methods

Product

Mode

Phone

Mode

Server Versions

Release 9 and later:

Cisco Unified

Communications

Manager

Phone

Mode

Release 8.x:

Cisco Unified

Communications

Manager

Discovery Method Non DNS SRV Record Method

A DNS SRV request against

_cisco-uds.<domain>

Use the following installer switches and values:

• AUTHENTICATOR=CUCM

• TFTP=<CUCM_address>

• CCMCIP=<CUCM_address>

• PRODUCT_MODE=phone_mode

High availability is not supported using this method of deployment.

Manual connection settings Use the following installer switches and values:

• AUTHENTICATOR=CUCM

• TFTP=<CUCM_address>

• CCMCIP=<CUCM_address>

• PRODUCT_MODE=phone_mode

High availability is not supported using this method of deployment.

Cisco Unified Communications Manager release 9.x and earlier—If you enable Cisco Extension Mobility, the

Cisco Extension Mobility service must be activated on the Cisco Unified Communications Manager nodes that are used for CCMCIP. For information about Cisco Extension Mobility, see the Feature and

Services guide for your Cisco Unified Communications Manager release.

Note

Cisco Jabber release 9.6 and later can still discover full Unified Communications and IM-only services using the _cuplogin DNS SRV request but a _cisco-uds request will take precedence if it is present.

Use the SERVICES_DOMAIN installer switch to specify the value of the domain where DNS records reside if you want users to bypass the email screen during the first login of a fresh installation.

Note

The services domain is read from a cached configuration if you are upgrading from Cisco Jabber for

Windows 9.2.

Cisco Jabber 10.6 Planning Guide

71

Planning Considerations

Recommended Connection Methods

Table 3: On-Premises Deployments for Cisco Jabber for Mac

Product Mode Server Versions Discovery Method

Full UC (default mode)

Release 9 and later:

• Cisco Unified Communications

Manager

A DNS SRV request against

_cisco-uds.<domain>

• Cisco Unified Communications

Manager IM and Presence

Service

Full UC (default mode)

Release 8.x:

• Cisco Unified Communications

Manager

• Cisco Unified Presence

A DNS SRV request against

_cuplogin.<domain>

Table 4: On-Premises Deployments for Cisco Jabber for Android and Cisco Jabber for iPhone and iPad

Product Mode

Full UC (default mode)

Server Versions

Release 9 and later:

• Cisco Unified

Communications Manager

• Cisco Unified

Communications Manager

IM and Presence Service

Discovery Method

A DNS SRV request against

_cisco-uds .<domain> and

_cuplogin.<domain>

Full UC (default mode)

IM Only (default mode)

IM Only (default mode)

Phone mode

Release 8.x:

• Cisco Unified

Communications Manager

• Cisco Unified Presence

A DNS SRV request against

_cuplogin.<domain>

Release 9 and later: Cisco Unified

Communications Manager IM and

Presence Service

A DNS SRV request against

_cisco-uds .<domain> and

_cuplogin.<domain>

Release 8.x: Cisco Unified

Presence

A DNS SRV request against

_cuplogin .<domain>

Release 9 and later: Cisco Unified

Communications Manager

A DNS SRV request against

_cisco-uds.<domain>

72

Cisco Jabber 10.6 Planning Guide

Planning Considerations

Product Mode

Phone mode

Sources of Authentication

Server Versions

Release 8.x: Cisco Unified

Communications Manager

Discovery Method

Manual connection settings or bootstrap file

Manual connection settings

Note

Cisco Unified Communications Manager version 9 and later can still discover full Unified Communications and IM-only services using the _cuplogin DNS SRV request but a _cisco-uds request will take precedence if it is present.

Table 5: Hybrid Cloud-Based Deployments

Server Versions Connection Method

Cisco WebEx Messenger HTTPS request against http://loginp.webexconnect.com/cas/FederatedSSO?org=<domain>

Table 6: Cloud-Based Deployments

Deployment Type

Enabled for single sign-on (SSO)

Not enabled for SSO

Connection Method

Cisco WebEx Administration Tool

Bootstrap file to set the SSO_ORG_DOMAIN argument.

Cisco WebEx Administration Tool

Sources of Authentication

A source of authentication, or an authenticator, enables users to sign in to the client.

Three possible sources of authentication are as follows:

• Cisco Unified Communications Manager IM and Presence—On-premises deployments in either full

UC or IM only.

• Cisco Unified Communications Manager—On-premises deployments in phone mode.

• Cisco WebEx Messenger Service—Cloud-based or hybrid cloud-based deployments.

Cisco Jabber 10.6 Planning Guide

73

Planning Considerations

High Availability

High Availability

High Availability for Instant Messaging and Presence

High availability refers to an environment in which multiple nodes exist in a subcluster to provide failover capabilities for instant messaging and presence services. If one node in a subcluster becomes unavailable, the instant messaging and presence services from that node failover to another node in the subcluster. In this way, high availability ensures reliable continuity of instant messaging and presence services for Cisco Jabber.

When using an LDAP or UDS contact source on Cisco Jabber for Mac and Cisco Jabber for mobile clients, high availability is not supported. High availability is only supported for LDAP (EDI) on Cisco Jabber for

Windows.

Cisco Jabber supports high availability with the following servers:

Cisco Unified Presence releases 8.5 and 8.6

Use the following Cisco Unified Presence documentation for more information about high availability.

Configuration and Administration of Cisco Unified Presence Release 8.6

Multi-node Deployment Administration

Troubleshooting High Availability

Deployment Guide for Cisco Unified Presence Release 8.0 and 8.5

Planning a Cisco Unified Presence Multi-Node Deployment

Cisco Unified Communications Manager IM and Presence Service release 9.0 and higher

Use the following Cisco Unified Communications Manager IM and Presence Service documentation for more information about high availability.

Configuration and Administration of IM and Presence Service on Cisco Unified Communications

Manager

High Availability Client Login Profiles

Troubleshooting High Availability

Active Calls on Hold During Failover

You cannot place an active call on hold if failover occurs from the primary instance of Cisco Unified

Communications Manager to the secondary instance.

74

Cisco Jabber 10.6 Planning Guide

Planning Considerations

High Availability for Instant Messaging and Presence

High Availability in the Client

Client Behavior During Failover

If high availability is configured on the server, then after the primary server fails over to the secondary server, the client temporarily loses presence states for up to one minute. Configure the re-login parameters to define how long the client waits before attempting to re-login to the server.

Configure Login Parameters

In Cisco Unified Communications Manager IM and Presence Service, you can configure the maximum and minimum number of seconds that Cisco Jabber waits before attempting to re-login to the server.

On the server, you specify the re-login parameters in the following fields:

Client Re-Login Lower Limit

Client Re-Login Upper Limit

Client Behavior During a Failover

The following figure shows the client's behavior when the Cisco Unified Communications Manager IM and

Presence service during a failover.

Figure 15: Client Behavior During a Failover

1

When the client is disconnected from its active server, the client goes from XMPPCONNECTED state to a FAILOVER state.

Cisco Jabber 10.6 Planning Guide

75

Planning Considerations

High Availability for Voice and Video

2

From a FAILOVER state, the client tries to attain a SOAPCONNECTED state by attempting

SOAPCONNECT_SESSION_P (as the primary server), and if that fails, attempts

SOAPCONNECT_SESSION_S (as the secondary server).

• If it is unable to attain SOAPCONNECT_SESSION_P or SOAPCONNECT_SESSION_S, the client re-enters into the FAILOVER state.

• From a FAILOVER state, the clients attempts to attain a SOAPCONNECT_P state, and if that fails, attempts to reach a SOAPCONNECT_S state.

• If the client cannot reach the SOAPCONNECT_P or SOAPCONNECT_S state, then the client does not attempt any more automatic connections to the IM&P server until a user initiates a login attempt.

3

From a SOAPCONNECT_SESSION_P, SOAPCONNECT_SESSION_S, SOAPCONNECT_P, or

SOAPCONNECT_S state, the client retrieves its current primary secondary XMPP server address. This address changes during a failover.

4

From a SOAPCONNECTED state, the client tries to attain an XMPPCONNECTED state by attempting to connect to the XMPPCONNECT_P state, and if that fails, attempts XMPPCONNECT_S state.

• If client cannot reach XMPPCONNECT_P or XMPPCONNECT_S state, then the client does not attempt any more automatic connections to the IM&P server until a user initiates a login attempt.

5

After the client is in an XMPPCONNECTED state, then the client has IM&P capability.

High Availability for Voice and Video

If one node in a subcluster becomes unavailable, voice and video failover to another node in the subcluster.

By default, it takes up to 120 seconds for a software phone device or desk phone to register with another node.

If this timeout period is too long, adjust the value of the SIP Station KeepAlive Interval service parameter for your node. The SIP Station KeepAlive Interval service parameter modifies all phone devices on Cisco Unified

Communications Manager. Before you adjust the interval, analyze the impact on the Cisco Unified

Communications Manager servers.

To configure service parameters for the node, in Cisco Unified Communications Manager Administration, select System > Service Parameters.

For a phone mode deployment using the non-DNS SRV record method, failover isn't possible for Voice and

Video, as there is only one Cisco Unified Communications Manager node specified.

Computer Telephony Integration

Cisco Jabber for Windows and Cisco Jabber for Mac support CTI of Cisco Jabber from a third party application.

Computer Telephony Integration (CTI) enables you to use computer-processing functions while making, receiving, and managing telephone calls. A CTI application can allow you to retrieve customer information from a database on the basis of information that caller ID provides and can enable you to use information that an interactive voice response (IVR) system captures.

For more information on CTI, see the CTI sections in the appropriate release of the Cisco Unified

Communications Manager System Guide. Or you can see the following sites on the Cisco Developer Network

76

Cisco Jabber 10.6 Planning Guide

Planning Considerations

Computer Telephony Integration

for information about creating applications for CTI control through Cisco Unified Communications Manager

APIs:

• Cisco TAPI: https://developer.cisco.com/site/jtapi/overview/

• Cisco JTAPI: https://developer.cisco.com/site/jtapi/overview/

Cisco Jabber 10.6 Planning Guide

77

Computer Telephony Integration

Planning Considerations

78

Cisco Jabber 10.6 Planning Guide

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement

Table of contents