Cisco Unified CallManager Developers Guide
Chapter 4. WebDialer API Programming
Downloads: This chapterpdf (PDF - 365.0KB) The complete bookPDF (PDF - 3.65MB) | Feedback

WebDialer API Programming

Table Of Contents

WebDialer API Programming

Definitions

Overview

Webdialer Servlet

Redirector Servlet

Changes in Release 5.0

Logging Mechanism Changes

Redirector Over HTTPS

Dial Rule Change Notification

WebDialer Support for Enhancements in CTI and JTAPI

Migration of Dial Rules Data

SIP Support in WebDialer

Increase in Thread Count to 3

Call Flows

Desktop-based Client Application Call Flow

Browser-based Application Call Flow

Interfaces

SOAP over HTTP Interface

makeCallSoap

endCallSoap

getProfileSoap

isClusterUserSoap

HTML over HTTP Interfaces

makeCall

makeCallProxy

WebDialer WSDL

Sample JavaScript


WebDialer API Programming


This chapter describes the Simple Object Access Protocol (SOAP) and HTML over HTTP (and HTTPS) interfaces used to develop customized directory search applications for Cisco Unified CallManager WebDialer Version 1.2, and contains the following sections:

Definitions

Overview

Call Flows

Interfaces

WebDialer WSDL

Sample JavaScript

Definitions

Cisco WebDialer Server

A server that hosts the Cisco Unified CallManager WebDialer application

Cisco WebDialer Application

The software that is installed on a Cisco Unified CallManager server. It enables the click-to-dial functionality by creating hyperlinked telephone numbers in a company directory. This functionality allows users to make calls from the web page by clicking on the telephone number of the person they are trying to call. The Cisco Unified CallManager WebDialer application consists of two Java servlets, the WebDialer servlet and the Redirector servlet.

WebDialer Servlet

A Java servlet that allows Cisco Unified CallManager users in a specific cluster to make and end calls, as well as access their phone and line configuration.

Redirector Servlet

A Java servlet that finds the Cisco Unified CallManager cluster for a request made by a Cisco WebDialer user. It redirects that request to the specific Cisco WebDialer server located in that user's Cisco Unified CallManager cluster.


Overview

Cisco Unified CallManager WebDialer, which is installed on a Cisco Unified CallManager server and used in conjunction with Cisco Unified CallManager, allows Cisco Unified IP Phone users to make calls from web and desktop applications. For example, Cisco Unified CallManager WebDialer uses hyperlinked telephone numbers in a company directory to allow users to make calls from a web page by clicking on the telephone number of the person they are trying to call.

The two main components of Cisco Unified CallManager WebDialer are the Webdialer Servlet and the Redirector Servlet.

Webdialer Servlet

The WebDialer servlet is a Java servlet that allows Cisco Unified CallManager users in a specific cluster to make and end calls, as well as to access their phone and line configuration.

Cisco WebDialer applications interact with the WebDialer servlet through two interfaces:

The SOAP over HTTP interface—This interface that is based on the Simple Object Access Protocol (SOAP) gets used to develop desktop applications such as Microsoft Outlook Add-in and SameTime Client Plug-in. Developers can use the isClusterUserSoap interface to design multicluster applications that require functionality similar to a Redirector servlet.

HTML over HTTP interface—This interface that is based on the HTTP protocol gets used to develop web-based applications such as the Cisco Unified CallManager directory search page (directory.asp). Developers who use this interface can use the Redirector servlet for designing multicluster applications.

Redirector Servlet

The Redirector servlet, a Java based servlet finds the Cisco Unified CallManager cluster for a request made by a Cisco WebDialer user. It redirects that request to the specific Cisco WebDialer server that is located in that user's Cisco Unified CallManager cluster. Availability of the Redirector servlet occurs only for multicluster applications and only for applications that are developed by using HTML over HTTP or secure HTTP (HTTPS) interfaces.

Figure 4-1 illustrates how a Redirector servlet redirects a call in a multicluster environment.

Figure 4-1 Multiple Clusters

Example of Cisco Unified CallManager WebDialer Using the Redirector Servlet

For example, consider three clusters, each one in a single city such as San Jose, Dallas, and New York. Each cluster contains three Cisco Unified CallManager servers with Webdialer servlets that have been configured for Cisco Unified CallManager servers SJ-CM1, D-CM2, and NY-CM3.

The system administrator configures the Webdialer servlets on any of the Cisco Unified CallManager servers by entering the IP address of that specific Cisco Unified CallManager server in the wdservers service parameter.

For information on configuring Webdialer and Redirector servlets, refer to the Cisco WebDialer chapter in the Cisco Unified CallManager Features and Services Guide, Release 5.0.

When a user who is located in San Jose clicks on a telephone number in the corporate directory search page that is enabled by Cisco Unified CallManager WebDialer, the following actions happen:

1. The Cisco Unified CallManager server sends an initial makeCall HTTP request to the Redirector servlet.

2. If this request is received for the first time, the Redirector servlet reads the Cisco Unified CallManager WebDialer server cookie and finds it empty.

For a repeat request, the Redirector servlet reads the IP address of the Cisco Unified CallManager WebDialer server that previously serviced the client and sends a isClusterUser HTTP request only to that server.

3. The Redirector servlet sends back a response asking for information, which results in the authentication dialog box opening for the user.

4. The user enters the Cisco Unified CallManager user ID and password and clicks the Submit button.

5. The Redirector servlet reads only the user identification from this information and sends a isClusterUser HTTP request to each Cisco Unified CallManager WebDialer server that has been configured by the system administrator.

Figure 4-1 illustrates how this request is sent to the Webdialer servlets that have been configured for SJ-CM1, D-CM2, and NY-CM3. Depending on the geographical location of the calling party, the WebDialer servlet from the cluster representing that location responds positively to the Redirector servlet. The remaining Webdialer servlets that were contacted return a negative response. The WebDialer servlet SJ-CM1 responds positively to the request because the calling party is located in San Jose (SJ-CM).

The Redirector servlet redirects the original request from the user to SJ-CM1 and sets a cookie on the user's browser for future use.

Changes in Release 5.0

The following changes to the Cisco Unified CallManager WebDialer were included in Cisco Unified CallManager Release 5.0.

Logging mechanism modified to apply changes to both WebDialer and Redirector

Redirector fully functional with HTTPS. The previous support for HTTPS was only partial.

WebDialer should subscribe for Dial Rule Change Notification.

Provided migration of Dial Rule data during an upgrade from Windows to Linux.

WebDialer support is provided for enhancements that were made in CTI and JTAPI.

Provided SIP support in WebDialer

Increased thread count to 3.

These enhancements are explained in detail in the sections that follow.

Logging Mechanism Changes

In the previous release the changes made to the logging were applied only to the Webdialer servlet. In this release the logging mechanism has been modified so that the changes are applicable to both the WebDialer and Redirector servlet.

The serviceability mechanism provided for applying the changes in one logger to another logger has been used. The fappender.jar is now included in the WebDialer class path to take care of this dependency.

Redirector Over HTTPS

Redirector support for HTTPS was only partial until the previous release. Requests to the WebDialer server were using HTTP as the protocol. Redirector now supports HTTPS completely.

Dial Rule Change Notification

In previous releases WebDialer was not subscribed to Change Notification from the Application dial rule table. The WebDialer service had to be restarted every time an add/update/delete was made to the dial rules. Starting with this release WebDialer subscribes to Change Notification from the Application dial rule table.

WebDialer Support for Enhancements in CTI and JTAPI

The following enhancements in CTI and JTAPI are supported in WebDialer:

WebDialer includes the necessary changes to accommodate the modified interfaces for QoS and SRTP.

WebDialer supports secure connections to CTI (TLS connection). For this feature, webdialer will be using the security API provided by JTAPI. Please refer to the Cisco Unified JTAPI Developers Guide for the JTAPI API. There is also a new Application User, "WDSysUser", which is used by WebDialer for obtaining the CTI connection.

The following configuration must be completed before WebDialer can be configured to open a CTI connection in secure mode.


Step 1 Activate the "Cisco CTL Provider " service from the Cisco Unified CallManager Service administration page.

Step 2 Activate the "Cisco Certificate Authority Proxy Function" Service.

Step 3 Download the "Cisco CTL Client" from the Application plugin and install it on any machine.

Step 4 Run the CTL Client, choose the option to "enable Cluster Security" and follow the instructions that are displayed. This requires USB E-tokens.

Step 5 To verify that cluster security is enabled, go to the Cisco Unified CallManager administration page and look at [System-> Enterprise Parameter configuration]. Look at the Security Parameters; the cluster security should be set to 1.

Step 6 In the Cisco Unified CallManager administration page, from the "UserManagement" drop-down menu select the "Application User CAPF Profile" option.

Step 7 Click "Add new" InstanceID.

Step 8 In the CAPF Profile configuration wndow, setup an InstanceID and CAPF profile for the InstanceID for the Application User "WDSysUser."

a. InstanceID: Enter the value of instance id, for example "001."

b. Certificate Operation: Select "Install/Upgrade" from the drop-down menu.

c. Authentication Mode: Select "By Authorization String" from the drop-down menu.

d. Authorization String: Enter the value of authorization string, for example "12345."

e. Key Size: Select key size from drop down menu, for example "1024."

f. Operation Completes By: Enter the date and time in following format yyyy:mm:dd:hh:mn where yyyy=year, mm=month, dd=date, hh=hour, mn=minutes, such as 2006:07:30:12:30.


Note If this date and time is past, then the certificate update operation will fail.


g. Ignore the Packet Capture Mode, Packet Capture Duration, and Certificate fields.

h. Certificate Status: Select "Operation pending" from the drop-down menu.

If anything else is selected, the certificate update will fail.


New Service Parameters

WebDialer has two new service parameters for CTI connection security. These are node-specific parameters.

CTI Manager Connection Security Flag—This required service parameter indicates whether security for the Cisco Unified CallManager WebDialer service CTI Manager connection is enabled or disabled.

If enabled (true), Cisco Webdialer will open a secure connection to CTI Manager using the Application CAPF profile configured for the instance ID (as configured in CTI Manager Connection Instance ID service parameter) for Application user WDSysUser. The default value is false.

Application CAPF Profile Instance ID: This service parameter specifies the Instance ID of the Application CAPF Profile for Application User WDSysUser that this Cisco Unified CallManager WebDialer server will use to open a secure connection to CTI Manager. You must configure this parameter if the CTI Manager Connection Security Flag parameter is enabled (true).

Algorithm:

1. Read the service parameters.

2. Get the node IP/name of the nodes where TFTP and CAPF are activated.

3. For the instanceID (input in service parameters), if the Certificate Operation is `Install/Upgrade' or `Delete', then delete the current certificates, if any.

4. If the Certificate Operation is not `Install/Upgrade' or `Delete', and there is a current certificate, use this certificate.

5. If there is no certificate present, request one using JTAPI API setSecurityPropertyForInstance; this will need username, instanceID, authCode, tftpServerName, tftpPort, capfServerName, capfPort, certPath, and securityFlag. This call will contact the TFTP server, download the certificate, contact the CAPF server, verify the CTL file, and request the client and server certificates.

6. If Step 5 is successful, then set the following on the ICCNProvider and call open().provider.setInstanceID(instanceID);provider.setTFTPServer(tftpServerName);provider.setCAPFServer(capfServerName);provider.setCertificatePath(certPath);provider.setSecurityOptions(securityFlag);

7. If Step 5 fails, then throw initFailedException. This can be seen in the WebDialer traces.

Install Changes

WebDialer rpm creates a new directory "/usr/local/cm/wd/wd-certificates/" and sets permissions for users on this directory, which is used to store the certificates.

Files Changed: /vob/ccm/Projects/CMAppServices/rpm/cm-webdialer.spec

Partition Support

WebDialer supports the partition information that is now provided by JTAPI. The WebDialer preferences page now includes information about the partition along with the line.

Migration of Dial Rules Data

The directory exports data into a CSV file. The CSV file points to a file in the same location, which has the dial rules in binary format as they are stored in the directory. The post-install script for WebDialer parses this CSV file, finds the file that has the encoded dial rules, decodes them, and populates the database with the dial rules.

SIP Support in WebDialer

WebDialer supports SIP phones in this release. CTI only supports the new SIP phones and not the existing SIP phones, so the same support is extended by WebDialer. The APIs provided by JTAPI are used to distinguish between these two kinds of phones and hide the unsupported phones from the user on the WebDialer preferences page.

Increase in Thread Count to 3

In previous releases, WebDialer supported only two concurrent threads. The performance testing for WebDialer shows better results (in terms of successful call rate) if the thread count is increased to 3. To increase performance, this change is being made for WebDialer in this release.

Call Flows

The call flows in this section describe the flow of events for client and browser-based applications that use Cisco Unified CallManager WebDialer, and should help you design customized applications for Cisco Unified CallManager WebDialer.

Desktop-based Client Application Call Flow

Figure 4-2 shows the call flow for an outgoing call from a client application such as Microsoft Outlook Plug-in to a WebDialer servlet. The user clicks the Dial or Make Call button in the address book of the client application. If the user is making a call for the first time, the application does not have authentication or configuration information on the user.

If the user makes a call for the first time:

1. The client sends a makeCallSoap request to the configured WebDialer servlet.

2. The WebDialer servlet attempts to authenticate the user. Figure 4-2 shows an authentication failure because the authentication information is incomplete or does not exist.

3. The WebDialer servlet sends an authentication failure response to the client application.

4. The client application displays a dialog box on the computer screen of the user asking for the user ID and password. The user enters this information and clicks the submit button. The user ID and password is now stored for future invocations of the application.

5. The application sends a repeat SOAP request to the WebDialer servlet. The request contains credential information on the user.

6. The WebDialer servlet authenticates the user.

7. The WebDialer servlet reads any missing configuration information in the request.

8. The WebDialer servlet returns a configuration error message to the client application.

9. The client application sends a getConfigSoap request to the WebDialer servlet.

10. The WebDialer servlet responds with the user's configuration information stored in the directory.

11. The client application displays a configuration dialog box on the user's computer screen asking the user to select or update the configuration. The user enters the information and clicks the submit button. The user's configuration information is now stored for future invocations of the application.

12. The client resends the makeCallSoap request to the WebDialer servlet. This request contains the user's configuration information.

13. The WebDialer servlet authenticates the user and dials the telephone number using the information contained in the makeCallSoap request. It responds to the client with a success or failure message.


Note The call flow goes directly to step 12:

If the credential and configuration information is already stored when the application is installed.

For all subsequent requests made by the user.


Figure 4-2 Cisco Unified CallManager WebDialer Call Flow for a Client-based Application

Browser-based Application Call Flow

Figure 4-3 shows the call flow for an HTTP based browser application such as a directory search page, personal address book, or the Cisco Unified CallManager directory search page (directory.asp).

The user clicks the Dial or Make Call button in the address book of the client application. If the user is making a call for the first time, the application does not have authentication or configuration information on the user.

Figure 4-3 Cisco Unified CallManager WebDialer Call Flow for a Browser-based Application

If the user makes a call for the first time:

1. The client sends a makeCall HTTP request to the configured WebDialer servlet. The query string contains the number to be called.

2. The WebDialer servlet authenticates the user. Authentication fails because the authentication information is incomplete or does not exist.


Note Authentication is successful if the user's credentials are sent with the request, and the call flow goes directly to number seven.


3. The WebDialer servlet sends an authentication dialog to the client browser for user authentication.

4. The user enters the user ID and password and clicks the Submit button.

5. The client sends a makeCallHTTP request containing the user's credentials to the WebDialer servlet.

6. The WebDialer servlet authenticates the user.

7. The WebDialer servlet reads the configuration information in the cookie which is sent with the request.

8. Assuming that the request is made for the first time, the servlet sends a response containing a cookie to the client's browser. The cookie containing the client's credentials is stored on the client's browser. The client's credentials are user ID, IP address, and the time of the request.

9. The user enters the updates in the configuration dialog box and clicks the Submit button.

10. The client's browser sends a makeCall HTTP request to the WebDialer servlet. The request contains a cookie with the credential and configuration information in parameter form.

11. The WebDialer servlet uses the credentials to authenticate the user and saves the configuration information in its memory.

12. The WebDialer servlet sends a makeCall confirmation dialog to the client's browser with the configuration information stored in a cookie. The cookie is stored on the client's browser for future invocations.

13. The Make Call dialog box appears on the user's computer screen. The user clicks the Dial button which sends another makeCall HTTP request to the WebDialer servlet.

14. The WebDialer servlet authenticates the user using the credentials in the cookie, retrieves the configuration information from the cookie, and makes the call.

15. The servlet responds by sending an endCall confirmation dialog to the user to end the call. The End Call dialog box appears on the user's computer screen and stays there for the amount of time configured in the service parameters.

For all subsequent requests, the call flow starts at number 12 and ends at number 15.

Interfaces

Cisco Unified CallManager WebDialer applications interact with the WebDialer servlet through two interfaces:

SOAP over HTTP interface— This interface is based on the Simple Object Access Protocol (SOAP) and is used to develop desktop applications such as Microsoft Outlook Add-in and SameTime Client Plug-in. Developers can use the isClusterUserSoap interface to design multi-cluster applications that require functionality similar to a Redirector servlet.

HTML over HTTP interface— This interface is based on the HTTP protocol and is used to develop web-based applications such as the Cisco Unified CallManager directory search page (directory.asp). Developers using this interface can use the Redirector servlet for designing multi-cluster applications.


Note The following files must be run to properly set the ENV variable and Java classes:
      installWDService.bat
      installWDSOAP.bat


SOAP over HTTP Interface

To access the SOAP interfaces for Cisco Unified CallManager WebDialer, use the Cisco Unified CallManager WebDialer Web Service Definition Language (WSDL) in the "WebDialer WSDL" section.

makeCallSoap

The makeCallSoap interface is accessed by initiating a SOAP request to the URL http://CCM-IP:8080/webdialer/services/WebdialerSoapService where CCM-IP is the IP address of the Cisco Unified CallManager server on which WebDialer is configured.

Parameter
Mandatory
Description
Data Type
Range Values
Default Value

Destination

Mandatory

Standard canonical form. For example +1 408 5551212 or extensions such as 2222.

String

None

None

Credential

Mandatory

The user ID or password of the user or proxy user. For more information on creating a proxy user, see the Cisco WebDialer chapter in the Cisco Unified CallManager Features and Services Guide, Release 5.0.

Refer to the credential data type in the "WebDialer WSDL" section.

None

None

Profile

Mandatory

The profile that is used to make a call. An example of a typical profile is a calling device such as an IP phone or line.

Refer to the profile data type in the "WebDialer WSDL" section.

None

None


Results

Refer to the "WebDialer WSDL" section for return values and their data type.

Error Code
Name
Type
Description
Action by application

0

responseCode

Integer

Success

Displays a dialog box.

responseDescription

String

Success

 

1

responseCode

Integer

Call failure error

Displays a relevant error message.

responseDescription

String

Call failure error

 

2

responseCode

Integer

Authentication error

Displays the authentication dialog where the user enters ID and password information.

responseDescription

String

User authentication error

 

3

responseCode

Integer

No authentication proxy rights

Void for user-based applications.

responseDescription

String

No authentication proxy rights

 

4

responseCode

Integer

Directory error

Displays an appropriate directory error message.

responseDescription

String

Directory error

 

5

responseCode

Integer

No device is configured for the user, or, there are missing parameters in the request.

The application initiates a getConfigSOAP request and displays the selected device and line to the user.

responseDescription

String

No device is configured for the user, or, there are missing parameters in the request.

 

6

responseCode

Integer

Service is temporarily unavailable.

Displays the appropriate error dialog with an option to try again.

responseDescription

String

Service is temporarily unavailable.

 

7

responseCode

Integer

Destination cannot be reached.

Displays the appropriate error dialog that allows the user to edit the dialed number.

responseDescription

String

Destination cannot be reached.

 

8

responseCode

Integer

Service error

Displays the appropriate error dialog.

responseDescription

String

Service error

 

9

responseCode

Integer

Service overloaded

Displays the appropriate error dialog with an option to try again.

responseDescription

String

Service overloaded

 


endCallSoap

The endCallSoap interface is accessed by initiating a SOAP request to the URL http://CCM-IP:8080/webdialer/services/WebdialerSoapService where CCM_IP is the IP address of the Cisco Unified CallManager server on which WebDialer is configured.

Parameter
Mandatory
Description
Data Type
Range Values
Default
Value

Credential

Mandatory

The user ID or password of the user or proxy user. For information on creating a proxy user, see the Cisco WebDialer chapter in the Cisco Unified CallManager Features and Services Guide, Release 5.0.

Refer to the credential data type in "WebDialer WSDL" section.

None

None

Profile

Mandatory

The profile that is used to make a call. An example of a typical profile is a calling device such as an IP phone or line.

Refer to the profile data type in the "WebDialer WSDL" section.

None

None


Refer to the "WebDialer WSDL" section for return values and their data type.

Error Code
Name
Type
Description
Action by application

0

responseCode

Integer

Success

Displays a dialog box on the computer screen.

responseDescription

String

Success

 

1

responseCode

Integer

Call failure error

Displays a relevant error message.

responseDescription

String

Call failure error

 

2

responseCode

Integer

Authentication error

Displays authentication dialog for user to enter user ID and password.

responseDescription

String

User authentication error

 

3

responseCode

Integer

No authentication proxy rights

Void for user-based applications.

responseDescription

String

No authentication proxy rights

 

4

responseCode

Integer

Directory error

Displays an appropriate directory error message.

responseDescription

String

Directory error

 

5

responseCode

Integer

No device is configured for the user, or, there are missing parameters in the request.

The Application initiates a getConfigSOAP request and displays the selected device and line to the user.

responseDescription

String

No device is configured for the user, or, there are missing parameters in the request.

 

6

responseCode

Integer

Service is temporarily unavailable.

Displays the appropriate error dialog with an option to try again.

responseDescription

String

Service is temporarily unavailable.

 

7

responseCode

Integer

Destination cannot be reached.

Displays the appropriate error dialog that allows the user to edit the dialed number.

responseDescription

String

Destination cannot be reached.

 

8

responseCode

Integer

Service error

Displays appropriate error dialog.

responseDescription

String

Service error

 

9

responseCode

Integer

Service overloaded

Displays the appropriate error dialog with an option to try again.

responseDescription

String

Service overloaded

 


getProfileSoap

The getProfileSoap interface is used by plug-in based clients and accessed by initiating a SOAP request to the URL http://CCM-IP:8080/webdialer/services/WebdialerSoapService where CCM-IP is the IP address of the Cisco Unified CallManager server on which WebDialer is configured.

Parameter
Mandatory/ Optional
Description
Data Type
Value Range
Default Value

Credential

Mandatory

User ID or password of the user or proxy user. For information on creating a proxy user, see the Cisco WebDialer chapter in Cisco Unified CallManager Features and Services Guide, Release 5.0.

Refer to the credential data type in the "WebDialer WSDL" section.

None

None

UserID

Mandatory

The user ID for which the configuration is requested.

String

None

None


Refer to the "WebDialer WSDL" section for return values and their data type.

Error Code
Name
Type
Description
Action by plug-in application

0

responseCode

Integer

Returns an array of phones or lines on the phone associated with the user. Refer to the Cisco Unified CallManager WebDialer WSDL for the WDDeviceInfo data type.

Displays a dialog box on the computer screen.

responseDescription

String

Success

 

deviceInfoList

Array

Returns an array of the the WDDeviceInfo data type.

 

1

responseCode

Integer

No device is configured for the user.

Displays an appropriate error message.

responseDescription

String

No device is configured for the user.

 

2

responseCode

Integer

Authentication error

Displays the authentication dialog where the user enters ID and password information.

responseDescription

String

User authentication error

 

3

responseCode

Integer

No authentication proxy rights.

Void for user-based applications.

responseDescription

String

No authentication proxy rights.

 

4

responseCode

Integer

Directory error

Displays an appropriate directory error message.

responseDescription

String

Directory error

 

6

responseCode

Integer

Service is temporarily unavailable.

Displays the appropriate error dialog with an option to try again.

responseDescription

String

Service is temporarily unavailable.

 

9

responseCode

Integer

Service is overloaded.

Displays the appropriate error dialog with an option to try again.

responseDescription

String

Service is overloaded.

 


isClusterUserSoap

The isClusterUserSoap interface is accessed by initiating a SOAP request to the URL http://CCM-IP:8080/webdialer/services/WebdialerSoapService where CCM-IP is the IP address of the Cisco Unified CallManager server on which WebDialer is configured.

This SOAP interface is used for multi-cluster applications that require functionality, similar to a Redirector servlet, for redirecting calls to the various locations where Cisco Unified CallManager WebDialer is installed on a network. The application uses this interface to locate and verify the Cisco Unified CallManager WebDialer servicing the user, followed by makeCall, endCall or getProfile requests to that WebDialer.

Parameter
Mandatory
Description
Data Type
Range of Values
Default Value

UserID

Mandatory

The user ID for which the the request is made.

String

None

None


Refer to the "WebDialer WSDL" section for return values and their data type.

Name
Type
Description

result

Boolean

The result is true if the user is present in the directory of the cluster. The result is false if the user is not present in the directory.


HTML over HTTP Interfaces

This section describes the HTML over HTTP interfaces.

makeCall

The makeCall interface is used in customized directory search applications. It is also used by the Cisco Unified CallManager directory search page (directory.asp). The makeCall interface is accessed by initiating an HTTP request to the URL http://<ipaddress>/webdialer/Webdialer. In this URL, ipaddress is the IP address of the Cisco Unified CallManager server for which WebDialer is configured.

This interface is used by browser-based applications in which the browser accepts cookies. The user profile exists only for the length of the session if the cookies are disabled in a browser. For a sample script that is used to enable directory search pages, go to the "Sample JavaScript" section.

Parameter
Mandatory
Description
Data Type
Range of Values
Default Value

destination

Mandatory

Destination number called by the application. Number is converted to a regular telephone number by applying the application dial rules. Refer to the Cisco WebDialer chapter in the Cisco Unified CallManager Features and Services Guide, Release 5.0.

String

None

None


Name
Description

result

Cisco Unified CallManager WebDialer displays the appropriate dialog and its applicable success or error message. It displays an authentication dialog if there is no active session.


makeCallProxy

The makeCallProxy interface is accessed by initiating an HTTP request to the URL http://ipaddress/webdialer/Webdialer?cmd=doMakeCallProxy. This interface is used by browser-based applications in which the browser accepts cookies. If the cookies are disabled in a browser, the user profile exists for only the length of the session.

The makeCallProxy interface can be used by applications such as a personal address book, defined in theUnified CMUser pages at http://cmserver/CMUser. The credential of the application is used, as a proxy, to make calls on behalf of users. Since these users have authenticated themselves before accessing theUnified CMUser page, they are not prompted again for their user ID and password. The application sends the user ID and password of the proxy user in the form of a query string in the request, or as a parameter in the body of the POST message.

For a sample script that is used to enable directory search pages, go to the "Sample JavaScript" section.

Parameter
Mandatory
Description
Data Type
Range of Values
Default Value

uid

Mandatory

The user ID for which the request is made.

String

None

None

appid

Mandatory

The userid of the application making a request on behalf of the user. For example, consider a Unified CM personal address book where the application allows authentication proxy rights. The appid parameter is used when the user logs in once; for example in the Unified CM User pages. After this login, other pages do not require the user to log in again. For web page applications that are not integrated, appid is the same as userid.

String

None

None

pwd

Mandatory

The password of the appid.

String

None

None

destination

Mandatory

The number to be called. This number is converted to an E.164 number by the dial plan service.

String

None

None


Name
Description

result

Cisco Unified CallManager WebDialer displays the appropriate dialog and its applicable success or error message.


WebDialer WSDL

The Web Service Definition Language (WSDL) for Cisco Unified CallManager WebDialer mentioned below is based on the WSDL specification. This WSDL for Cisco Unified CallManager WebDialer is also available on the Cisco Unified CallManager WebDialer server installation at:

http://CCM-IP:8080/webdialer/services/WebdialerSoapService?wsdl

Use this specific WSDL and the interfaces mentioned in this document to develop customized applications for Cisco Unified CallManager WebDialer. For a list of references on Cisco Unified CallManager, SOAP, and WSDL, refer to the "Related Documentation" section in the Preface.

<wsdl:definitions xmlns:tns="urn:WebdialerSoap" 
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" 
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/" 
targetNamespace="urn:WebdialerSoap" name="urn:WebdialerSoap">
	<wsdl:types>
		<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:tns="urn:WebdialerSoap" targetNamespace="urn:WebdialerSoap">
			<xsd:import namespace="http://schemas.xmlsoap.org/soap/encoding/"/>
			<xsd:complexType name="CallResponse">
				<xsd:sequence>
					<xsd:element name="responseCode" type="xsd:int"/>
					<xsd:element name="description" nillable="true" type="xsd:string"/>
				</xsd:sequence>
			</xsd:complexType>
			<xsd:complexType name="Credential">
				<xsd:sequence>
					<xsd:element name="userID" nillable="true" type="xsd:string"/>
					<xsd:element name="password" nillable="true" type="xsd:string"/>
				</xsd:sequence>
			</xsd:complexType>
			<xsd:complexType name="UserProfile">
				<xsd:sequence>
					<xsd:element name="user" nillable="true" type="xsd:string"/>
					<xsd:element name="deviceName" nillable="true" type="xsd:string"/>
					<xsd:element name="lineNumber" nillable="true" type="xsd:string"/>
					<xsd:element name="supportEM" type="xsd:boolean"/>
					<xsd:element name="locale" nillable="true" type="xsd:string"/>
				</xsd:sequence>
			</xsd:complexType>
			<xsd:complexType name="GetConfigResponse">
				<xsd:sequence>
					<xsd:element name="responseCode" type="xsd:int"/>
					<xsd:element name="description" nillable="true" type="xsd:string"/>
					<xsd:element name="deviceInfoList" nillable="true" 
type="tns:ArrayOfWDDeviceInfo"/>
				</xsd:sequence>
			</xsd:complexType>
			<xsd:complexType name="WDDeviceInfo">
				<xsd:sequence>
					<xsd:element name="deviceName" nillable="true" type="xsd:string"/>
					<xsd:element name="lines" nillable="true" type="tns:ArrayOfstring"/>
				</xsd:sequence>
			</xsd:complexType>
			<xsd:complexType name="ArrayOfWDDeviceInfo">
				<xsd:complexContent>
					<xsd:restriction base="soapenc:Array">
						<xsd:attribute ref="soapenc:arrayType" 
wsdl:arrayType="tns:WDDeviceInfo[]"/>
					</xsd:restriction>
				</xsd:complexContent>
			</xsd:complexType>
			<xsd:complexType name="ArrayOfstring">
				<xsd:complexContent>
					<xsd:restriction base="soapenc:Array">
					<xsd:attribute ref="soapenc:arrayType" wsdl:arrayType="xsd:string[]"/>
					</xsd:restriction>
				</xsd:complexContent>
			</xsd:complexType>
		</xsd:schema>
	</wsdl:types>
	<wsdl:message name="makeCallSoap0In">
		<wsdl:part name="cred" type="tns:Credential"/>
		<wsdl:part name="dest" type="xsd:string"/>
		<wsdl:part name="prof" type="tns:UserProfile"/>
	</wsdl:message>
	<wsdl:message name="makeCallSoap0Out">
		<wsdl:part name="Result" type="tns:CallResponse"/>
	</wsdl:message>
	<wsdl:message name="endCallSoap1In">
		<wsdl:part name="cred" type="tns:Credential"/>
		<wsdl:part name="prof" type="tns:UserProfile"/>
	</wsdl:message>
	<wsdl:message name="endCallSoap1Out">
		<wsdl:part name="Result" type="tns:CallResponse"/>
	</wsdl:message>
	<wsdl:message name="getProfileSoap2In">
		<wsdl:part name="cred" type="tns:Credential"/>
		<wsdl:part name="userid" type="xsd:string"/>
	</wsdl:message>
	<wsdl:message name="getProfileSoap2Out">
		<wsdl:part name="Result" type="tns:GetConfigResponse"/>
	</wsdl:message>
	<wsdl:message name="isClusterUser3In">
		<wsdl:part name="userid" type="xsd:string"/>
	</wsdl:message>
	<wsdl:message name="isClusterUser2Out">
		<wsdl:part name="Result" type="xsd:boolean"/>
	</wsdl:message>
	<portType name="WebdialerSoapService">
		<wsdl:operation name="makeCallSoap">
			<wsdl:input message="tns:makeCallSoap0In"/>
			<wsdl:output message="tns:makeCallSoap0Out"/>
		</wsdl:operation>
		<wsdl:operation name="endCallSoap">
			<wsdl:input message="tns:endCallSoap1In"/>
			<wsdl:output message="tns:endCallSoap1Out"/>
		</wsdl:operation>
		<wsdl:operation name="getProfileSoap">
			<wsdl:input message="tns:getProfileSoap2In"/>
			<wsdl:output message="tns:getProfileSoap2Out"/>
		</wsdl:operation>
		<wsdl:operation name="isClusterUserSoap">
			<wsdl:input message="tns:isClusterUser3In"/>
			<wsdl:output message="tns:isClusterUser2Out"/>
		</wsdl:operation>
	</portType>
	<binding name="WebdialerSoapService" type="tns:WebdialerSoapService">
		<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
		<wsdl:operation name="makeCallSoap">
			<soap:operation soapAction="urn:makeCallSoap"/>
			<input>
				<soap:body use="encoded" encodingStyle= 
"http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:WebdialerSoap"/>
			</input>
			<output>
				<soap:body use="encoded" encodingStyle= 
"http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:WebdialerSoap"/>
			</output>
		</wsdl:operation>
		<wsdl:operation name="endCallSoap">
			<soap:operation soapAction="urn:endCallSoap"/>
			<input>
				<soap:body use="encoded" encodingStyle= 
"http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:WebdialerSoap"/>
			</input>
			<output>
				<soap:body use="encoded" encodingStyle= 
"http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:WebdialerSoap"/>
			</output>
		</wsdl:operation>
		<wsdl:operation name="getProfileSoap">
			<soap:operation soapAction="urn:getProfileSoap"/>
			<input>
				<soap:body use="encoded" encodingStyle= 
"http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:WebdialerSoap"/>
			</input>
			<output>
				<soap:body use="encoded" encodingStyle= 
"http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:WebdialerSoap"/>
			</output>
		</wsdl:operation>
		<wsdl:operation name="isClusterUserSoap">
			<soap:operation soapAction="urn:isClusterUserSoap"/>
			<input>
				<soap:body use="encoded" encodingStyle= 
"http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:WebdialerSoap"/>
			</input>
			<output>
				<soap:body use="encoded" 
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:WebdialerSoap"/>
			</output>
		</wsdl:operation>
	</binding>
	<service name="WebdialerSoap">
		<port name="WebdialerSoapService" binding="tns:WebdialerSoapService">
		<soap:address location= 
"http://WebDialer_ip_address:8080/webdialer/services/WebdialerSoapService"/>
		</port>
	</service>
</wsdl:definitions> 

Sample JavaScript

This JavaScript is a sample script that is used to enable Cisco Unified CallManager WebDialer from a directory search page.

Single Cluster Applications

This script is used for single cluster applications if all users are in only one cluster.

 
   
function launchWebDialerWindow( url ) {
    webdialer=window.open( url, "webdialer", "status=no, width=420, height=300, 
scrollbars=no, resizable=yes, toolbar=no" );
  }
 
   
  function launchWebDialerServlet( destination ) {
    url = 'http://<%=server_name%>/webdialer/Webdialer?destination=' + 
escape(destination);
    launchWebDialerWindow( url );
  }
!These functions can be called from the HTML page which has a hyperlink to the phone 
number to be called. An example of it is:
<TD><A href="javascript:launchWebDialerServlet( <%= userInfo.TelephoneNumber %> )"><%= 
userInfo.TelephoneNumber %></A>&nbsp;</TD>
 
   

Multiple Cluster Applications

This script is used if all users are spread across different clusters.

function launchWebDialerWindow( url ) {
    webdialer=window.open( url, "webdialer", "status=no, width=420, height=300, 
scrollbars=no, resizable=yes, toolbar=no" );
  }
 
   
  function launchWebDialerServlet( destination ) {
    url= 'http://<%=server_name%>/webdialer/Redirector?destination='+escape(destination);
    launchWebDialerWindow( url );
  }
!These functions can be called from the HTML page which has a hyperlink to the phone 
number to be called. An example of it is:
<TD><A href="javascript:launchWebDialerServlet( <%= userInfo.TelephoneNumber %> )"><%= 
userInfo.TelephoneNumber %></A>&nbsp;</TD>