Introduction

In an earlier article, Nick Williams introduced the Session Initiation Protocol (SIP) and the Java SIP Servlet API. That article focused on the lower-level aspects of both SIP and SIP Servlets. It also alluded to how much easier it would be to create next generation telecommunication applications. In this article, that promise is fulfilled as you see how easy it is to build a basic contact center application using the SIP Servlet API.

Back to top

SIP and the SIP Servlet API

SIP is an application-layer protocol used to create and manage media sessions between devices. These sessions are established and controlled through the use of SIP messages. After establishing the sessions, any media can be exchanged, although SIP does not concern itself with this aspect of the session. The SIP RFC (3261) defines several key concepts and elements that can be found in a SIP network.

• A User Agent (UA) is an end-point that enables you to create and manage a communication session. A UA can be a SIP telephone or a software application; it is responsible for session setup and management tasks such as transfer, termination, and service invocation. In addition, the UA can identify user availability and negotiate session capability, that is, the media supported.
  
  
• A session is established by the UA (known as the caller) inviting another UA (known as the callee) to join a communication session.
  
  
• A SIP message is a text-based entity, of which there are two types: requests and responses. A request is sent from one UA to another, which in turn sends a response.
  
  
• A SIP Proxy Server is usually responsible for handling registrations, implementing call-routing policies, and performing authentication and authorization. Its most basic task is to ensure that a request is sent to another entity closer to the targeted user. A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it. A SIP message might pass through several SIP Proxy Servers as it travels to the callee UA. A UA is usually configured to send any requests it originates to a specific SIP Proxy Server.
  
  
• A SIP address, or SIP URL, is used to uniquely identify a user and is used during the creation of a communication session. It is very similar to an e-mail address except that it has a sip: prefix. For example, the telephone on your desk might have this SIP address sip:user@194.195.100.20.
  
  

In addition to providing SIP functionality, a Proxy Server can act as a Service Creation Platform.

The SIP Servlet API has been developed under the Java Community Process (JCP) and provides an open, Java-based Service Creation platform on which to create and deploy telecommunication applications. Although you can't get around having to understand the SIP protocol, you can work at a higher level than would otherwise be the case. This has obvious benefits regarding the speed and ease with which new services can be developed.

Another SIP benefit is that it is a well-supported and open standard. In developing the contact center, I also show how easy it is to build a solution using a wide range of hardware and software from a variety of vendors.

Back to top

Introducing the contact center

Modern, commercial contact center solutions are large and complex applications. In addition to core application functionality there is also the need to integrate with a wide range of hardware and software such as IVR servers, media servers, CRM, HR database, and so on. Typical functionality includes, but is not limited to:

• Automatic/Intelligent Call Distribution, which allows a customer call to be efficiently and effectively routed to the most appropriate agent.
  
  
• Queue Management, which enables multiple queues to be defined and configured, each of which can be associated with a business process. Among other things, this typically involves specifying announcements, music on hold, and the association of agents with the queue. Ideally, there would be support for the dynamic reallocation of resources based upon demand.
  
  
• Flexible IVR menu system, which can be used to direct calls and obtain information such as account numbers. A customer's query can possibly be answered by the IVR system alone, self-service. Obtaining an account balance is one example of this.
  
  
• Multiple Customer Contact Channels, which must be supported, such as voice, e-mail, instant messaging, fax, and so on. Voice is no longer the only communication medium. Today's customers want to contact a company through a variety of channels.
  
  
• CRM. Knowing the customer history increases efficiency and enhances the customer experience. It can also be used to analyze customer behavior in general and also to identify and educate customers that call frequently.
  
  
• Employee Management, which allows the definition of a hierarchy of management from agent to supervisor to manager.
  
  
• Agents, which are typically trained to support one or more lines of business and can be associated with one or more queues as needed.
  
  
• Supervisors, which are responsible for organizing queues and agents, and also acts as an escalation point.
  
  
• Issue Tracking allows the linking, storage, and display of different customer communications while tracking an issue through to resolution.

Obviously, developing a solution with such a breadth and depth of functionality can be a complicated exercise. Luckily, only a small subset of contact center functionality can be used to demonstrate the ease with which a modern application can be developed.

Back to top

Contact center features

Because I am developing a basic contact center application, the functionality is constrained; although, it is sufficient enough to serve my purpose. To this end, I have identified three contact centers:

• The Administrator is responsible for the management and configuration of the application.
• The Agent is responsible for handling customer calls.
• The Customer dials in to speak with an agent.

The actual application functionality is summarized as:

• Queue Management allows an administrator to create queues and to assign agents to a queue. The queue can also be configured to play various announcements, such as a welcome message and periodic progress reports. If the queue is full, the call is rejected with an appropriate message.
  
  
• An agent can be defined with general employee details and skill set attributes. The agent skills set can be used when assigning agents to a queue. An agent can also modify their status. The routing engine uses the status when determining which agent handles a customer call. For example, an agent with a status of Busy is not presented with a call.
  
  
• A simple customer database has been implemented to demonstrate CRM functionality. The routing engine uses Caller Line Identification to match an entry in the customer database. The relevant customer history is then displayed to an agent.
  
  
• Basic run-time statistics are displayed for each queue, such as the number of callers waiting, the number of calls handled, and the average wait time.
  
  
• Various events are logged by the system, such as customer dial-in, call transferred to agent, call completed, and so on. These are subsequently used by the reporting system.

The whole application is Web based, and all administrator and agent activities are conducted using a standard Internet browser. Agents and administrators have user accounts and require authenticated logins. The Queue Management and Statistics screens are shown below.

Back to top

Network components and software of the contact center architecture

One key benefit of the new open standards pervading the telecom world is the ease with which hardware and software components from different vendors can be integrated. The contact center uses a variety of hardware and software provided by different vendors:

• WebSphere Application Server Version 5.0
• Oracle RDBMS for storing configuration and event information
• Ubiquity SIP A/S, which is a SIP Proxy and SIP Servlet container
• Cisco 5380 Universal Gateway, which is SIP-enabled and contains a PSTN gateway
• Snowshore A1 Media Server, which is a SIP-enabled media server used to play IVR and mixed media sessions

Figure 3 contains an architecture diagram that illustrates how these components interact.

The agent and administrator functions and the queue and intelligent routing modules are part of the Web application that runs on a Java 2 Platform, Enterprise Edition (J2EE) application server. This communicates with the SIP Application Server that is responsible for handling all incoming and outgoing calls and for controlling the media server. All configuration, customer information, and event logging is recorded by the Web application to the database for persistence and reporting purposes.

Back to top

Contact center scenario

Customer dial-in is a typical action in which the customer is queued until an appropriate agent is available to speak with them. The path this scenario takes through the application is as follows.

Incoming calls from the PSTN network are received by the Cisco gateway and translated into a SIP INVITE request. Calls directed at a certain number can be configured so that the SIP messages are sent to a specific SIP Application Server. At the SIP Application Server the request is translated into a call to the service method of the contact center servlet. It is then presented to the Web application as a new dialog. Listing 1 shows the handling of a customer call.

public void newDialog(DialogDescriptor a_DialogDescriptor) throws RemoteException
{
    final String source = a_DialogDescriptor.getSource();
    final String dest = a_DialogDescriptor.getDest();
    final String di = a_DialogDescriptor.getDialogIdentifier();

    // Play the Welcome message to the Customer.
    IvrService..executeScript(IvrScripts.THANK_YOU_FOR_CALLING, di);
    IvrService..executeScript(IvrScripts.ONE_SECOND_SILENCE, di);
    IvrService.executeScript(IvrScripts.PLEASE_HOLD, di);

    // Create a Call object and place it on the Queue.
    final Call c = new Call(source, dest, di);

    QueueManager.enQueue(c);
}

At this point, the customer session has been established. A welcome script is now played to the customer through the media server before an attempt is made to transfer the call to an agent.

When attempting to transfer the call, various information is extracted from the INVITE request. The number used to dial the contact center is used to determine which queue the call should be placed on. Once assigned to a queue, the intelligent routing engine extracts information that might identify a customer. This information is used to both select an appropriate agent and to ensure that customer information is displayed to that agent. Different rules can be applied to this process. The default rule attempts to route the call to an agent who has dealt with that customer in the recent past and who is, therefore, more familiar with that customer's history.

After an agent has been selected, that agent is connected to the customer. The contact center application dials out to the agent to establish a session. Upon successful completion, both the agent session and customer session are combined through the media server to allow a voice call to proceed. Although not strictly necessary in this scenario, the use of a media server allows additional parties, such as a supervisor, to enter a call at any time.

Note that either party can terminate the call at any time, after which an agent is available to process new calls. An agent can also optionally mark himself or herself as Busy or even Logout, in which case they are not presented with calls.

Back to top

In conclusion

This article has described how easy it is to create a basic telecommunications application using SIP servlets. The use of open standards such as SIP, together with Java programming, has radically simplified the task of creating complex applications. Although not necessarily feature-rich, the contact center application has shown how a wide variety of hardware and software components based upon open standards can combine to produce an effective solution. Furthermore, the speed with which such solutions can be developed is an order of magnitude greater than ever before. Indeed, this solution took less than one month to complete, and a sizeable percentage of that effort was expended on the user interface! I encourage you to experiment with the SIP Servlet API and see for yourself just how quickly you use use it to help with your own problems.

Resources

• Read the author's first article, SIP: Creating next-generation telecom applications, (developerWorks, September 2003) as an introduction to this paper.
  
  
• See the specs for the SIP Servlet API on the Java Community Process' home page to learn more about the API.
  
  
• Find a complete synopsis of the SIP protocol at the the SIP Center.
  
  
• A thorough, 269-page paper on the Session Initiation Protocol is also available online.
  
  
• Ubiquity is where the author puts his developing ideas to work.
  
  
• You'll find articles about every aspect of the wireless frontier in the developerWorks Wireless technology zone.
  
  
• Also see the Wireless zone tutorials page for a complete listing of free wireless-focused tutorials from developerWorks.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Introduction
• SIP and the SIP Servlet API
• Introducing the contact center
• Contact center features
• Network components and software of the contact center architecture
• Contact center scenario
• In conclusion
• Resources
• About the author
• Comments