Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Casestudy: IP Telephony Integration

Casestudy: IP Telephony Integration

This item in japanese


In this second InfoQ case study (see the first on the Brasilian National Healthcare System) we take a look at an interesting solution in the telephony space. LiteScape Technologies is a privately held software company that provides applications that unify the communications of an organization. These applications securely integrate IP telephony with business applications and corporate data on any IP device, including IP phones, mobile devices and PCs. LiteScape’s solutions have been implemented across multiple vertical industries including retail, manufacturing, professional services, financial services, public sector and healthcare. Today's modern work environments feature a wide array of communications mediums such as email, conference calls, and online presentations. Each has its own user interface, methods of initialization and more. LiteScape's software applications pull them all together in a way that both simplifies their use and allows for powerful integration between previously disparate data and devices.

This case study takes a look under the hood at LiteScape's software solution, guiding you from requirements through an architectural overview of their Java and .NET implementation, and then zooming on some interesting technical aspects of their project including phone integration with WebEx/LiveMeeting, integration between Java/.NET interop, HTTP vs. IPC communication between systems installed on the same machine, and finally some overall lessons learned from the project.

Domain Analysis

Being a provider of end-to-end business solutions means that LiteScape must support a variety of inputs and outputs such as:

  • Outlook/Exchange
  • Outsourced Collaboration (WebEx, Live Meeting etc.)
  • CRM Solutions (ex., MS-CRM)
  • Directory Services (LDAP / Active Directory)
  • Presence servers (MS-LCS, AOL)
  • Communication Infrastructure (IP-PBX's, MS-LCS, Desktop Phones)

These services are spread out over the network and are accessed through a number of varying protocols and interfaces. Customers then want to be able to access the unified information through Web and desktop clients as well as on their IP-based phones.

In essence phones are becoming multimedia endpoints that directly integrate with and complement all that a user does on their PC. They also act as intelligent devices that provide advanced communications capabilities in lieu of a PC. The phone is an extended piece of desktop real estate that is often better suited than the computer to simplify and automate communication tasks. Examples of such usage include one-touch applications to start/join conference calls, the display of a contact's presence on the phone prior to calling that contact, and access to corporate and personal directory services. Companies are also using the IP phone network to broadcast messages such as fire alarm warnings which include visual maps of the quickest exit path for each employee based on their phone's physical location in the building.

Extending an application to an IP phone is not a simple process. In most cases the UI can't just be ported. Considerations must be made to provide a user interface that works well with the input and screen specification of the phone. It is much more about extending the "presence" of the application or the data to the phone instead of simply "porting" the application to the phone. Once this process has been completed however logging into an online conference can be as simple as displaying the calendar entry for the meeting on the phone and then pushing a "Join Conference" button on the phone to simultaneously join both the audio conference and the Web conference (on the users PC) portions of the collaboration session.

When LiteScape first started offering IP phone integration features the tasks where specific in nature. For example in some environments (such as retail and manufacturing) computers are scarce and not accessible to everyone due to budget constraints and the nature of the particular business but an IP phone is available. As a result companies are able to use IP phone applications for such activities as timecard entries or multi-media product training. Law firms have also found that the ability to perform tasks such as directly logging time spent talking to clients and tying it to a client/matter record after any phone call directly from the phone is invaluable in terms of reducing time and paper costs. LiteScape's offerings provide application level integrations with areas such as directory services and time/billing management. The technology is also becoming a platform that other companies such as Infosys and WebEx are using to extend their products and services to the IP phone level.

Solution Overview

The LiteScape architecture can be broken down into three main elements. The first element is the third party communications infrastructure components a company has in place such as PBX systems, IP Phones, and enterprise business applications and directories. The second architectural element is the LiteScape Multi-modal Application Platform (MAP). Finally, the third element of LiteScape's architecture includes clients which use MAP to extend its applications to both a user's IP phone and their desktop. Clients include Outlook/Notes plugins, a standalone desktop client, and a Web browser.

Figure 1: An Overview of the LiteScape Architecture

As the LiteScape product has evolved so has the technology behind it. The product started as a Java-based solution. However, the need to integrate with Microsoft Unified Communications required the company to begin leveraging .Net as a part of their infrastructure. Today both Java and .Net are used on the back end and the front end with Java Web Start and .NET clients, support for Windows 2003 with IIS and Java-based integrations with products such as Sun's Java Media Framework server.

For Java development they use the IntelliJ IDE and Visual Studio.NET for .NET development. The LiteScape server installs on Windows 2003 on top of IIS and also includes a number of Windows services to support integrations written in .Net. Concurrently a copy of Apache Tomcat is installed on a different port to run any necessary Java components. The Java portion of the server makes extensive use of API's such as Apache Axis to provide Web services support. Both Web servers run side by side on the same machine. On the client side of the equation the .Net based OnCast Client provides desktop access on Windows XP and 2003. For enterprises needing Linux support a Java Swing Web Start client is provided.

 Figure 2: The Components of the Map Server

Figure 2 shows the moving parts of the MAP server. IIS and Windows services written in .NET provide functions such as the OnCast Directory module. Tomcat services and Java runnables provide functionality such as the SIP Gateway. Java-based Web services are deployed as servlets using Apache Axis. Finally, some modules cross the Java and .NET runtimes such as the OnCast Presence and Computer Telephony Integration (CTI) modules.

After the architecture itself, the next aspect of the system which stands out is the varying technical protocols that all come together to provide a unified communications experience for the user as illustrated in Figure 2.

Figure 3: An Overview of the Communications Protocols Used

The LiteScape OnCast Client (OC Client) is a desktop application that displays messages from the MAP server as well as interacts with desktop applications such as address books and Microsoft Outlook. It also may launch third party applications such as Web browsers and WebEx to facilitate communications functions such as online conferencing. The OnCast Client uses a communications layer (OC CIL) to communicate the LiteScape MAP server. This communication is performed through a variety of protocols based on the task that is being performed. For real time communications, protocols such as SIP are the most effective. Other activities such as authentication and personalization are handled by Web services. The MAP service also provides the clients with access to third party elements such as directory services like Microsoft Active Directory and OpenLDAP. The MAP Server may also initiate functions on IP phones networks running on third party IP-PBX's such as Cisco CallManager, Avaya Communication Manager, or Asterisk. Communication to directory services is handled through the platform specific protocol of each. Protocol/transport technologies such as XML, HTTP, Java Telephone API, and SNMP may be used for IP-PBX communication based on the back end system.

Drill Down 1: WebEx/LiveMeeting Integration

One example of the type of application / IP phone integration that LiteScape provides is conferencing support using WebEx/Microsoft LiveMeeting. Many people find the process of starting or joining an online conference frustrating with the various URLs, dial in numbers, and access codes needed. LiteScape automates this entire process so it can be initiated from the phone but also integrate with WebEx/LiveMeeting on the user's desktop.

The typical use case, where the user has been invited to a WebEx/LiveMeeting session, can proceed in either of two ways. First the user can manually add the invite to their calendar. The invitation can also be added automatically to the user's MS-Outlook/Exchange calendar by having OnCast server extensions that monitor invitation emails as an email server, such as Exchange, receives them. At this point the integration process is ready to proceed.

Before the meeting is scheduled to start the OnCast MAP server, (using IP Phone protocols), can send an OnCast Multimedia message (OCM) to the user's phone announcing the WebEx/LiveMeeting session. The OCM structure provides a collection that includes an XML scripting payload document and associated content needed for the LiteScape platform's bi-directional multi-media content delivery between various communication end-points, such as the desktop agents, phones, IP/analog speakers, etc.

The OCM structure includes support for basic forms of content such as: text, audio, image, voice or composite content handlers for: collaboration, RSS feeds, stock quotes, multiple choice surveys, MS-Power-Point presentations, Adobe PDF files, etc.

LiteScape OCM contains an XML based ‘payload' document that references the necessary attributes, properties and multi-modal event processing requirements that are to be carried out.

The following OCM payload snippet is for an organized session that includes users both on Cisco and Avaya type IP phones participating in a collaborative session:

<LDAPDN>CN=John Coyle,CN=Users,DC=litescape,DC=local|AD</LDAPDN>
<ServerLDAPID />
<ProviderID>IP-PBX 1</ProviderID>
<ProviderSource>IP-PBX 1</ProviderSource>
<Prefix />
<Email />
<DeviceType>Cisco 7961</DeviceType>
<EmergencyRingTone />
<NormalRingTone />
<FileName />

<Survey />
<Stocks />
<RSSFeeds />
<Workflow />

<UserID>Samira Kashani</UserID>
<LDAPDN>CN=Samira Kashani,CN=Users,DC=litescape,DC=local|AD</LDAPDN>
<ServerLDAPID />
<ProviderID>IP-PBX 1</ProviderID>
<ProviderSource>IP-PBX 1</ProviderSource>
<Prefix />
<Email />
<DeviceType>Cisco IP Communicator</DeviceType>

<PassCode />

<Priority />
<WebExMeetingID />
<InviteesGroup />

The OCM may include an embedded/linked image of the user requesting the conference call, an attachment or link to content such as a PowerPoint presentation associated with the call or an audio clip (embedded or linked) associated with the meeting. The user then can select to join the conference call from their phone. At this point the MAP server will then receive a request to start a WebEx/LiveMeeting session. The MAP server will notify the IP PBX to initiate the call portion of the WebEx/LiveMeeting conference. It will also communicate with the OnCast Client on the desktop which will automatically launch a WebEx session on the user's desktop and log them into the conference session. This sequence is shown in figure 4:

Figure 4: The Process of Launching a WebEx Session from an IP-Phone

Drill Down 2: Java and .NET

Figure 2 illustrates the components in the LiteScape MAP Platform server. The MAP Platform server makes extensive use of both Java and .NET technologies. Components such as the OnCast Directory are written in .NET and run as Windows Services communicating with the IIS instance installed. Other components such as the SIP Gateway are written in Java. Finally, the MAP Platform also includes hybrid components that make use of both Java and .NET such as the OnCast Presence and Computer Telephony Integration modules.

LiteScape chose to leverage both Java and .NET technologies for a number of reasons. First their customer had a strong desire to run desktop clients that integrated in Windows. They also wanted access to platform specific data such as Outlook Address Books, which can be accessed using Microsoft's MAPI interface. Finally, there was a requirement to provide single sign on security. By leveraging .Net LiteScape could use Windows Authorization and Domain Security. All of these items were in addition to the need to access Java services such as Sun's Java Media Framework server. A best of breed solution also simplified deployment. Many of LiteScape's customers already were leveraging Microsoft technologies. As a result IIS had been previously installed for other purposes.

In order to support such a hybrid architecture platform agnostic communications were needed. The .NET and Java components running in the MAP server offer XML based Web services for many common functions. TCP and SIP-based protocols are also used by components.

Options such as JNI and other .Net to Java integration libraries were not chosen for a number of reasons. LiteScape's architects had not had good experiences using such technologies previously. They were also concerned about possible roadblocks that might develop when trying to implement real time communications. Most importantly LiteScape did not want to be bound to the limitations of a third party integration library. They did not want to chance development of a key technology in their stack being discontinued or not rich enough feature wise.

LiteScape's architects work within a world of coexistence instead of trying to use one technology to solve all of their needs. For example it makes logical sense to use the Java Telephone API with devices that support it when providing such features as call control. Other integrations such as with Exchange and Active Directory, are more easily programmed with .Net. The final piece of the puzzle is connecting these varying technologies together.

An example of the various pieces interoperating across technologies is when the CTI engine receives a call. It will then fire an event to any interested party one of which is the SIP Gateway written in Java. A typical business case is to supplement the basic information available when a call comes into an enterprise with directory and business information about the person calling. To perform this functionality the SIP Gateway makes a request via Web-services to the .NET based OnCast Directory component. After supplementary information is retrieved, the SIP Gateway can then notify the OnCast Client via SIP/CSTA presenting the user with the additional information about the person calling them.

Drill Down 3: Simplifying Communications with the OnCast Client and Outlook/Notes Plugin

A specific example of the type of unified communication experience provided by LiteScape's technologies is the Outlook integration plugin. Among its features is the ability to right click on a name in an email and initiate a phone/conference call.

Technically, a number of steps are performed to allow this action to happen.

The Outlook Plugin is written in .NET and its install also includes the .NET-based OnCast Communications Layer (CIL) an application independent module that provides services such as loading of contacts, update user status (presence), P2P messaging, and SIP messaging. The OnCast CIL has an HTTPListener on a separate thread which listens to a TCP (local IP port to receive commands for any of the main OC CIL commands. It starts as a socket server and processes requests (Dial, Conference, Broadcast, Collaboration & remote call-control requests) as they come in over HTTP. This allows commands to be issued with simple URLs such as:

Dial: [Number]

Figure 4: The Path of an Example Command From the HTTPListener to the OnCast Directory

As figure 4 illustrates the http call is translated into a HTTPCommand object in the .NET based OnCast CIL library. It can then trigger a CIL Command which causes the OC CIL client to communicate with the MAP Server to perform operations like initiating a call. From a protocol standpoint, the workflow of the request starts as HTTP, is translated into internal .NET method calls, then sent over the wire as a Web Services Request, and finally executed by the MAP server as a IP-PBX request to start a call.

The obvious question with this method of integration is why is the HTTP protocol used on the client instead of pure .NET integration between the OnCast Client or Outlook plugin and the OnCast CIL communications library.?The reasoning for this design was two fold. First providing a HTTP-based API allows other clients written in technologies such as Java Swing to access the same functionality. Second, in LiteScape's experience Outlook Plugins are prone to crashes. By keeping the integration as thin as possible, a plugin crash will not take down the OnCast CIL services running on a client computer. Outlook can then simply be restarted and the communications process attempted again by the user.

Lessons Learned / Best Practices

During the development of the LiteScape server and client platform components their engineers learned a number of valuable lessons:

  • Components on each platform should be as agnostic as possible for easier integration at later dates. For example if an encryption library was used in Java, LiteScape required a corresponding library existed for .Net. Similar processes were followed when considering third party technologies.
  • If unsure about third party components, integrate at the transport layer instead using platform independent protocols such as those mentioned above.
  • Pay close attention to platform specific communications characteristics such as line feeds and buffering and the conversion of Unicode characters.
  • The community and availability of components is smaller in the .Net space then in Java. However, being able to pick up the phone and call an 800 number for technical support was invaluable. Diagnosing an issue in Java or a Java related library often involves searching knowledge bases and mailing lists. In comparison Microsoft support representatives are often able to pinpoint issues with components such as IIS.
  • IP Phones are a fast moving technology that can only be fully supported using best of breed strategies. A one-size-fits-all approach will not address every customers' needs.
  • Use the protocol or technology that fits your needs. A 5-10 second addition of latency in an email due to protocols is acceptable. This is completely untrue however in something like a phone call where milliseconds count.

Future Directions

LiteScape will continue their use of best of breed technologies. Due to the changing nature of the IP phone, Voice over IP and collaboration space, support must continually be added for new Phone makes and models and communications enhancements in technologies such as WebEx and Microsoft Live Meeting. LiteScape is also looking to continue broadening their integration into application areas such as CRM, Inventory Management, and Human Resources. On the technical side they are exploring the possibility of deploying their .NET based server components on Linux based servers using the Mono library.

In summary LiteScape strove to not be a "guinea pig" for the technologies they used. They let each mature and didn't try to make their customers rely on technologies that they themselves were not comfortable using yet. When the time did come to broaden their support for more applications they made the transition gradually. The result is a system that allows enterprises to access their services efficiently and effectively providing value to their businesses.

Rate this Article