This document describes the software applications developed around the Cisco IP telephony solution deployed at INRIA Rocquencourt.
The Cisco CallManager is the cornerstone of the IP telephony solution deployed at INRIA Rocquencourt. It runs a set of software applications which form the call-processing component of the Cisco IP telephony solution. The CallManager also provides tools for phones, dial plan and directory (LDAP) administration as well as open telephony application programming interfaces (TAPI, JTAPI).
The Cisco IP Phones (currently, 7940 and 7960 IP Phones run at INRIA Rocquencourt) can be plugged on any Ethernet / IP network. Each Cisco IP phone supports an XML / HTTP navigator as well as an HTTP server.
The software developments efforts associated with the Cisco IP telephony solution mainly involved three components which are the XML / HTTP navigator, the HTTP server (both residing in the Cisco 79xx ip phones), and the Java Telephony Application Programming Interface (JTAPI) which is run by the CallManager. All of the programs have been developed using Sun's JDK1.3.1.
Although incomplete, the JTAPI implementation provided by Cisco is
quite powerful. In order to get used to this interface, we first
decided to develop an application to monitor the calls that took place
in our IP telephony network. This could be easily done through the
Cisco JTAPI implementation, and we'll describe the way to do it in the
next paragraph.
For a complete description of the Sun Microsystems JTAPI, please refer
to Sun JTAPI
.
The first thing to do is to bring up a connection to the CallManager's
JTAPI implementation. This can be done by creating a
JtapiPeer object through the use of the static method
getJtapiPeer from the object
JtapiPeerFactory :
// providing the null parameter will permit to get the default
JtapiPeer object residing on the system, e.g. the JtapiPeer
JtapiPeer peer = JtapiPeerFactory.getJtapiPeer(null);
Once the JtapiPeer object has been created, we are able
to register to the CallManager by authenticating ourselves :
Provider provider = peer.getProvider("192.168.1.1,
login=login;passwd=passwd");
The IP address mentioned above must be the one of a running CallManager in a cluster, and the credentials must correspond to a registered user in the CallManager who have been granted both CTI application use and control of the devices to monitor by the CallManager administrator. For a description of the way to grant these rights please refer to the CallManager administration pages.*
From this point, many JTAPI events can be processed by our application. The next table shows the Java-JTAPI interfaces implemented by our application :
INTERFACE
|
IMPLEMENTED METHOD
|
CallControlCallObserver
|
callChangedEvent
|
CiscoProviderObserver
|
providerChangedEvent
|
Building the Java code associated with the
callChangedEvent method, one can control the behavior of
an application upon reception of one or several JTAPI events from the
JTAPI interface of the CallManager. Our choice was to display a frame
showing details of the calls occuring on the IP telephony network
such as the numbers involved in the call and the telephony states
of the call (ALERTING, CALL_IN_PROGRESS, DIALING_NUMBER, IN_CALL,
ON_HOOK...).
The following diagram describes the behavior of this application :
The Cisco IP phones (7940 and 7960) come with both an XML / HTTP
navigator and an HTTP server. The XML / HTTP navigator is able to
interpret a set of XML objects and tags defined by Cisco, which can be
displayed as text, images, directories, input forms and others.
The HTTP server keeps track of network statistics on the phone as well
as its network configuration. The XML object
<CiscoIPPhoneExecute> can be used to push a request to the phone
through its internal HTTP server.
In the following example, an external application running on computer
192.168.1.1 stimulates the Cisco IP phone's HTTP server to make the
phone's HTTP navigator reach XML page at URL
http://192.168.1.2/javaServlet.
Please refer to this page to get a piece of the Java code
corresponding to this example :
HTTP-Java request
Please refer to this document to get a complete description of the
Cisco XML objects :
CiscoIpPhoneServicesApplicationDevelopmentNotes
The CallManager comes with an integrated LDAP directory to manage internal CallManager users information such as extension number. This directory is accessible through the 'directories' key on any Cisco 7940 or 7960 IP phone. The last item (named 'Corporate Directory') in the list shown when pressing the 'directories' key gives access to the internal LDAP directory of the CallManager :
1 Missed call
2 Received calls
3 Placed calls
4 Corporate directory
Our purpose was to change the last item's title and pointer from CallManager's internal directory to INRIA's LDAPv3's directory. The LDAP directory currently running is at INRIA is an OpenLDAP directory. Cisco Does not recommend to integrate any LDAP directory other than Netscape Directory or Active Directory so it was decided to redirect some of the URL parameters in the CallManager configuration to home built Java servlets.
In order to modify the URL pointed by fourth item of the menu accessed through the 'directories' key of the Cisco IP phone, we changed the 'URL Directories' enterprise parameter in the CallManager. A small Java Servlet is now running at the new address :
We assume that CallManager has IP address 192.168.1.1 and that our sevlet engine has IP address 192.168.1.3
The Java servlet running at URL
http://192.168.1.3/ourDirectory serves as a redirector to
another servlet which is actually the LDAP search tool.
Please refer to this page to see the Java code associated with the
first servlet : main servlet
From this point, this is what we can see when pressing the 'Directories' key from any Cisco IP Phone :
1 Missed calls
2 Received calls
3 Places calls
4 Corporate directory INRIA
And the last item will point to URL :
http://192.168.1.3/directorySearchTool. The Java code
associated with this second servlet is basically made of
<CiscoIPPhoneInput> and
<CiscoIPPhoneDirectory> XML objects.
In an hybrid (classical telephony + ip telephony system) environment, it can be useful for the Cisco IP phones to consult a directory (either personal or corporate, or both of them) upon reception of a call in order to display the name of the caller (note that Cisco IP phones will display the name of the caller if it matches a physical device registered in the CallManager). This is the purpose of the application we will describe in the next paragraph.
Apart from the CallManger, five components come up to complete the
system :
- a JTAPI based monitoring application (as described at the top of this
document)
- a corporate LDAP directory
- an LDAP directory running on the CallManager which holds all of the
user's personal directories
- a Java servlet ready to answer to Cisco IP phone's HTTP requests
- the XML / HTTP navigator that comes up with the Cisco IP phones
When a monitored IP phone is alerted, the CallManager informs the JTAPI based monitoring application running on computer 192.168.1.1. This application will request the alerted phone to reach the Java servlet running on computer 192.168.1.3, and to provide the calling number in order to start a directory search first in the personal directory of the corresponding alerted user,and second in the corporate directory. The search results will be finally displayed on the alerted phone's screen.
In the following diagram, only the corporate directory search is described (no seach in any personal directory takes place)
at step 4, the string form of the request pushed to the Cisco IP
phone's HTTP server is :
String firstParameter = new String("4321");
String secondParameter = new String ("1234");
String query = "XML=" +
URLEncoder.encode("<CiscoIPPhoneExecute>\n<ExecuteItem
URL=\"http://192.168.1.2/javaServlet?" +
firstParameter + "&" +
secondParameter "\" />\n<
/CiscoIPPhoneExecute>");
auteur : Philippe Sultan ------- date de mise à jour : 17 juillet, 2003