Voice over IP in the Eclipse Communication Framework

Size: px
Start display at page:

Download "Voice over IP in the Eclipse Communication Framework"


1 F Voice over IP in the Eclipse Communication Framework Moritz Post Master Thesis Supervisor: Prof. Dr. rer. nat. Andreas Künkler Trier,

2 Abstract This project discusses the integration of Voice over IP technology into the Eclipse Platform. Voice Communication, as the most direct form of interaction, is gaining more and more adoption in an internet based world. While the number of technologies for this task is steadily growing, incompatibilities between the standards arise. To unite the various different VoIP technologies in one all encompassing framework, the Eclipse Communication Framework is used. Exemplary, this project will investigate the Jingle standard, an open Voice over IP protocol. We will gain insights into the protocol characteristics as well as a possible implementation. With this knowledge we integrate the Jingle functionality into the Eclipse Communication Framework by abstracting the Jingle protocol. This will allow accessing any VoIP technology through one unified API.

3 Contents 1 Introduction Unified Communication Voice over IP SIP Session Initiation Protocol H IAX InterAsterisk exchange Skype Jingle The Eclipse Platform Eclipse Technologie Technology XMPP and Jingle XEP-0166: Jingle Smack API Eclipse Communication Framework Lightweight Container Architecture Adaptable Container Namespaces and IDs Integrating Jingle into the ECF Call API Design of the Jingle Provider Using the Existing XMPP Provider Infrastructure Entry Point to the Jingle Provider Smack API Abstraction via the Call API Providing the Call UI

4 Contents IV Call Action Call View Future User Interface Developments Testing of the Jingle Provider Summary Conclusion Future Prospects References Glossary

5 List of Figures 1.1 Eclipse architecture (source: eclipse.org) IQ-Based Conversation Jingle session management Enhanced debugger of the Smack API library ECF Container Architecture Adaptable pattern Plugin dependencies of the Jingle provider Relations between ECF APIs, ECF providers and the Smack API Phases of the Jingle provider creation and setup Adaptable pattern applied to the ECF Architecure of the Jingle provider Call action embedded into the ECF user interface Preliminary user interface view for the Call API Network topology of the test environment

6 1 Introduction The world of software development is changing. Up to the early 80s, software development was executed by teams of locally joined developers. They were situated in the same office building and collaboration was as easy as walking over the hallway. All of this has changed since the rise of the internet. Oftentimes teams are spread all over the country or even all over the world. What once was the hallway has now become the wire of the internet. So whereas the communication becomes more and more difficult, the complexity of modern software projects is steadily increasing. This disparity is met with numerous technological approaches like , messaging boards, bug tracking systems, version control software, team management software etc.. All of those attempts have one shortcoming: They are indirect. They do not provide immediate feedback and therefore have limitations in speed and quality of communication. Although posting a message to some system and waiting for a reply is good, it poses a break in the thought process and makes it harder to create collaborate ideas. To increase the level of immediacy, other forms of technology do exist: internet chats and instant messaging services. Those technologies provide nearly instant feedback and let multiple clients take part in one conversation. Those real-time communication technologies do have one shortcoming though. In contradiction to the communication on the hallway, they do not transfer the emotions and the subtle undertones of a face-to-face meeting. To bring across those details, two decisive factors are required: voice and facial expression of the counterpart. As this fact is not entirely surprising, many technologies have focused on making these services available. The telephone exists for more than a century but it is only now, with modern digital technology, that video conferencing is possible. The main advantage of the digital transmission versus the

7 1.1 Unified Communication 2 established analog telephone is the improved voice quality, the easier administration and its low cost profile. The only thing required is an internet connection. Although audio and video communication provide the most direct way to communicate, it also requires a lot of attention from the user and therefore other indirect technologies have a right to exist as well. The need for audio communication in the digital age has manifested itself into the term Voice over Internet Protocol respectively Voice over IP (VoIP). It describes the process to transmit voice from one client to another (or multiple others). The term is very ambiguous as it does not make any assumptions about how to transmit the digital data. Therefore a lot of different approaches to this problem have been taken. A more thorough description will be presented in chapter Unified Communication This multitude of different communication technologies have led to a point where it is necessary to have multiple client applications installed in order to be reachable on every channel. This makes it harder to administer each communication facility and leads to information overkill as many different systems have to be observed. In the end more time is spend with the technology than with the actual communication. To overcome this obstacle one unified technology is required which supports a multitude of communication channels. This is even more correct in the world of software development. Where it is only the traffic and/or an instant messenger which needs to be taken care of in private life, the situation gets much more complex when doing software development. Projects which rely solely on the wire of the internet to synchronize development efforts have a multitude of systems running to streamline the development process. Good examples for these kinds of projects are open-source projects. This (usually) decentralized form of development is governed by participation rather than dictation. It is therefore essential to manage the communication process as efficiently as possible. In the world of open source development one platform is gaining more and more attention as both a development tool and a desktop application framework: the Eclipse platform [ecla]. Eclipse is the de facto standard in the Java [jav] IDE domain and is also supporting a wide variety of other languages like c++, ruby, php, groovy etc.. The ability to extend its functionality via plugins makes eclipse an outstanding development platform. In fact, this doc-

8 1.2 Voice over IP 3 ument is written using eclipse and the texlipse [tex] plugin for L A TEX. So how does the eclipse platform improve communication? For that purpose the Eclipse Communication Framework (ECF) [ecf] has been introduced. It is housed under the belt of the eclipse foundation [eclb] and acts as a centralized facility to aggregate communication channels. A more in depth description will be presented in chapter 1.3. As pointed out previously, the most direct way of communication is a face-toface conversation. Where this is not possible, the second best way is voice or video communication. And this is where this project comes into play. Although the ECF is a great project in itself, the VoIP facilities are not fully developed yet. It will be the goal of this project to bring VoIP capabilities to the ECF via an established voice protocol. This will enable teams of developers to be working within eclipse and to initiate a direct contact to their fellow team mates. This shortened route of communication will simplify the development process and increase the productivity as there is no delay in communication. Additionally there is no need to install any third party tools. It is all bundled within one unified entity: the eclipse platform. 1.2 Voice over IP This chapter will provide a description ofthe most common Voice over IP technologies. Among those are official standards as well as custom solutions from individual companies. When talking about internet telephony we have to pinpoint some key characteristics which are important. Usually a call can be divided into three phases: connection establishment, voice transmission and terminating the connection. There are multiple protocols available to handle those aspects and in some standards it is not specified how to transmit the actual voice data but just how to initiate and terminate a call session. Due to the package based nature of the internet, delivering speech in a satisfying manner is more difficult than via the analog telephone. The custom term for this is the quality of service (qos). The quality of the communication is determined by the following factors: Available bandwidth The available bandwith determines the maximum quality of the voice data. To use this resource as efficiently as possible different codecs exist to compress the voice data. Network latency Latency describes the amount of time it takes for a packet to travel from the source to its destination. If this delay gets too big a noticeable

9 1.2 Voice over IP 4 stutter can be heard in the voice transmission. Some VoIP technologies tackle this problem by using a dynamic codec, which is able to fallback to a lower voice quality. This degrades the voice quality but is usually less troublesome than noticeable breaks in the communication. Packet loss Packet loss describes the loss of some voice data during the transmission. Depending on the transmission process this requires to resend the packet or to ignore the loss. If the loss is not big it can usually be compensated but big losses result in noticeable lag. Jitter Jitter is a term for fluctuations in the latency of a transmission. It can have a similar effect as packet loss if the variance is too big. This is especially important when packet B arrives earlier than packet A. Echo When using a speaker on the client side it is possible that the microphone is also picking up the outputted audio stream from the speakers. This can create an echo effect or even worse a feedback loop. Modern protocols are able to compensate this problem by filtering out frequencies which resemble transmitted audio data. Security Security is not a bad factor per se. It might become an issue when the en- and decoding of the voice data is too complex for the hardware. This has the same effect as latency and will degrade the voice quality or even provoke lag. We will now examine several popular VoIP implementations and/or specifications, to see the different approaches to the described difficulties. Besides those technologies numerous other solutions exist. Some of them are heavily used by the gaming community, like TeamSpeak [ts] or Roger Wilco [rw]. Although they have proven to be reliable, they are not described here in greater detail since they are more specific to certain usage scenarios (like online gaming) SIP Session Initiation Protocol The SIP [sip]protocol is a widely spread standard developed by the Internet Engineering Task Force (IETF) [iet]. Because of its open nature hardware of different manufacturers can work together in a heterogenic environment. The user is identified by a SIP-address which has the format of an URI [uri] (e.g. The connection to a remote client is initiated by contacting a SIP-server, which is reachable via a regular DNS [dns] lookup. The server negotiates the connection details between the two clients. This negotiation process establishes the common

10 1.2 Voice over IP 5 characteristics between the two clients. Among those characteristics is the so called payload, which is a list of available voice codecs and their available qualities. The server compares those details and establishes the greatest common denominator. When the call is picked up remotely, the voice data is transmitted in a peer-to-peer manner, without involving the negotiating server. Since SIP only provides negotiation services, a second standard is used for the data transmission. This so called Real-Time Transport Protocol (RTP) [rtp]. The RTP is also specified by the IETF and is capable to package and send streams of data. It does not only support audio but also video or text data streams. It is multicast capable (many clients in one session) and uses the UDP port to be as efficient as possible. In today s emerging VoIP telephony for home users, the SIP protocol plays an important role as it is used by most VoIP providers. They also provide the facilities to map the common number based ids to the SIP-addresses. It is therefore possible to use a regular analog telephones as a VoIP telephone when combined with a little box in between (on the client side) H.323 The H.323 [h32] specification has been introduced by the International Telecommunication Union [itu], a sub-organization of the United Nations. It is targeted on the transfer of audio and video data over IP-based networks. Similarly to the SIP standard, the H.323 specification uses the RTP technology for the data transfer. H.323 also provides a server which is called a gateway in this context. Its job is to mediate the routing and the call details. A main advantage of the H.323 standard was its early introduction. It has become quite popular and provides some parts for the ISDN-technology. H.323 is also the underlying protocol of the famous Microsoft NetMeeting application. Compared to SIP the protocol is more tied to the telecommunication world. SIP is designed for the internet and offers a more HTTP like syntax. Depending on the usage scenarios both technologies do have their strengths and weaknesses although SIP is likely to be the protocol of the internet based future IAX InterAsterisk exchange IAX [iax] is a protocol introduced by the open source telephony engine Asterisk [ast]. Due to its free-of-charge nature, the Asterisk software has gained quite a lot

11 1.2 Voice over IP 6 of popularity in small telephony setups. The software can be easily extended to accommodate different usage scenarios. The main focus of the IAX protocol is simple configuration through NAT based networks. The signaling and the data stream both use one single UDP port, which makes it easy to configure in a network. During the design of the protocol, low bandwidth requirements were important as well. The protocols control signals are all binary based. This makes the communication very efficient compared to SIP or H.323. It is therefore possible to use IAX with an analog modem Skype Skype [skyb] is a very popular VoIP application among private users. The application itself is free of charge. It uses a proprietary protocol, which is not exposed to the public. It is therefore not known how secure and reliable the Skype application actually is. The company behind Skype, Skype Technologies [skyc] (in the meantime taken over by ebay) claims, that the communication is secured by AES-256 [aes] with to Bit keys. The voice quaility is known to be very good since modern codecs like SVOPC (16kHz), AMR-WB (16kHz), G.729 (8kHz) and G.711 are used. The Skype application also provides the ability to make phone calls into the regular phone network and to obtain a regular telephone number to get called from the phone network. For these services additional payment is necessary. Other possibilities are conference calls with multiple clients and video telephony. In addition to voice/video communication, Skype supports instant messaging, multi client chats, file transfers and numerous other features. It is also possible to buy special phone hardware which includes a skype client. Another interesting aspect of Skype is its mobile spin-off. A special Skype client for mobile devices (using Windows Mobile [win]) allows to place free-of-charge phone calls from mobile devices. Some mobile providers prohibit the usage in order to protect their market share Jingle Jingle [xepa] is a Peer-to-Peer extension to the Extensible Messaging and Presence Protocol (XMPP) [xmp]. XMPP originated from the Jabber instant messaging protocol, which has now been standardized by the IETF [iet]. The main idea behind XMPP is to act as an underlying protocol, to enable services such as instant messaging, presence notification or file transfers. Due to its flexible nature, the XMPP standard can be extended with custom capabilities. Such an extension is the Jingle

12 1.3 The Eclipse Platform 7 protocol, which has been introduced by Google Inc. [gooa] in December, 2005 for their own XMPP based instant messaging application Google Talk [goob]. Shortly afterwards the Jingle extension has been proposed for standardization as XEP [xepa] by the XMPP Standards Foundation (XFS) [xfs]. More information on XMPP and Jingle can be found in chapter The Eclipse Platform With a broad overview of the VoIP landscape we can now focus on the technology to unite these communication technologies under one umbrella application. To approach this endeavor, the Eclipse technology with its Eclipse Communication Framework is going to be used. Eclipse has its origin in the Websphere project by IBM. Starting as a commercial software product for Java development, it has been released under an open source license (the CPL) in November Accompanying this step, a so called Board of Stewards has been introduced. This committee consisted of members from NX Software Systems, Rational Software, Red Hat, SuSE, TogetherSoft, Sybase, Fujitsu, Hitachi, HP, SAP, the Fraunhofer Institute (ipsi), Ericsson and Intel to name some of the more popular representatives. Those institutions had a tight grip on the development process, which made it hard for outsiders to participate in the development process. To open up those hardened structures, the Board of Stewards announced Eclipse s reorganization into a not-for-profit corporation in February This step reduced IBM s influence and opened access to public contributions. The organization is now controlled by the so called Board of Directors. In August 2004 it consisted of Members from Ericsson, HP, IBM, Intel, MontaVista Software, QNX, SAP, Serena Software and Actuate. This new and open form of the Eclipse community helped to gain more popularity and made it more interesting for outside contributors to participate. In the past few years, the term Eclipse has become rather ambiguous. In its early incarnations, it was only promoted as a Java IDE with strong extendibility. With the introduction of Eclipse version 3.0, the underlying foundation has been switched to the OSGi [osg] runtime and the user interface elements were decoupled from the platform. This allowed using Eclipse as a platform for standalone tools and applications. From their on Eclipse was advertised as a platfrom for application development, tooling and everything else.

13 1.3 The Eclipse Platform Eclipse Technologie In the previous chapter we saw where the eclipse platform originated from and where it stands today. We will now focus on some of the technical aspects, which describe the inner workings of the Eclipse Platform. Most important is the general understanding of the plugin mechanisms and how these plugins make up the Eclipse platform as it is recognized today. Due to its very good Java development tools, most people think of Eclipse as an IDE for Java development. The tools provided for java coding, debugging, launching, monitoring etc. seam to define the IDE. But that is not the case. The Java tools are completely self-contained as a set of plugins known under the name Java Development Tools (JDT) [jdt]. The IDE could smoothly run without those plugins. There just wouldn t be any support for programming in Java. Other tools like the plugins of the Plugin Development Environment (PDE) [pde] could still be used. Concluding the above, there seems to be a core component of the Eclipse platform, which can be extended to add additional functionality to Eclipse. In fact this is exactly the architecture intended by Eclipse. Looking at figure 1.1, we see how Eclipse is structured to be as configurable and extendable as possible. Fig Eclipse architecture (source: eclipse.org)

14 1.3 The Eclipse Platform 9 Figure 1.1 shows how the Eclipse platform is extended with functionality for Java and Eclipse plugin development as it is distributed as the Eclipse IDE. As can also be seen, there are ways to add custom features to the Eclipse platform. These additions provide new capabilities for the IDE. When looking at the Eclipse Platform box of the figure, we see that there are several elements constituting the whole. On the bottom of the platform is the platform runtime environment. This is the actual core of the Eclipse technology and is mainly responsible for managing the plugin lifecycles and the plugin dependencies. Since Eclipse 3.0 this lose coupling of plugins is framed by the OSGi technology which uses the term bundle for individual components (plugins). A bundle can be started and stopped, and when carefully composed this is even possible during runtime. Despite standardization, the OSGi specification offered some additional benefits for bundle definitions: Ability to require a certain version of a runtime environment (e.g. Java 1.5) Usage of lazy loading (bundle is only started when accessed) or instantiation on platform startup Ability to require other bundles based on their versioning number (min and/or max version) Support for localization and internationalization An Activator can be defined, which is notified when the plugin is started and/or stopped Ability to expose specific packages in the current bundle to external bundles These bundle definition features play along very well with the Eclipse specific notion of the so called plugin extension points. These extension points define an interface to already existing plugins and can also be provided by custom plugins to extend their functionality. The JDT for example is connected to the eclipse eco system just by using the eclipse extension points in combination with the OSGi bundle concept. This includes adding user interface elements as well as underlying functionality like the internal java compiler etc.. The core functionality of the extension point mechanism and the OSGi runtime is only about 5 Megabyte in size. This minimum configuration of an Eclipse based application is than extended by some commonly used components. Among these elements is the entire area of user interface components. The main window of an eclipse application is called the workbench and consists of the contained views, actions, menus etc. The technology to display these elements is called the Standard Widget Toolkit (SWT) [swt] and is somewhat similar to Java Swing. Its

15 1.3 The Eclipse Platform 10 main difference to Swing is that it does not draw all the elements by itself but instead dispatches some of the drawing work to the underlying operation system. In consequence the user interface elements look more like the native widget set on the particular platform. It does also mean, that for each support platform, a native SWT assembly has to be maintained. Currently supported platforms are Windows (32 and 64bit), Windows Vista (experimental Windows Presentation Foundation (WPF) support), Linux (GTK2) and Mac OSX (Carbon). On top of the more basic SWT resides the JFace library [jfa]. JFace provides a higher level of abstraction for more advanced GUI elements like trees and tables and makes the usage of SWT easier in general. Besides the user interface features some more components complete Eclipse as a developer IDE. Among those are the facilities for the Help system. Every plugin is able to make a contribution to the Eclipse help pages by make use of some extension points. Another important aspect for programming language support is the debug interface. It allows to use the existing debugging user interface components for common tasks like breakpoints, stepping through code, variable inspection etc.. Of course these features are highly depended on the language to support in the IDE. To access remote repositories in version control systems the team plugin provides appropriate features. Out of the box, support for CVS [cvs] is provided but other versioning system can be added as well. A popular example is the subversive [sub] project providing support for the subversion version control software. As could be shown, the Eclipse platform is a powerful tool. Its easy extendibility makes it the de facto standard in the world of software tooling and the ever growing number of plugins and applications founded on the Eclipse platform pay testament to that fact. One of those many extensions to Eclipse is the Eclipse Communication Framework which we use to bring Voice over IP support to the Eclipse cosmos. We will have a closer look at the ECF in chapter 2.2.

16 2 Technology In this chapter we will explore the two main technologies used in this project. For one this is the Jingle specification, which defines a possible Voice over IP implementation. The other important aspect is the Eclipse Communication Framework (ECF). This extension to the Eclipse platform (see chapter 1.3.1) integrates many features used in collaboration software directly into the Eclipse workbench. 2.1 XMPP and Jingle When discussing the Jingle protocol, we inevitable have to discuss the XMPP protocol. XMPP is the communication protocol forming the foundation of the Jingle technology. As described in chapter it is an internationally recognized instant messaging standard, which is used in many different applications. In practice instant messaging is not limited to person-to-person conversation. Application to person or application to application exchange is also possible. This potential makes XMPP a very powerful tool. Imagine an application where some problem occurs (possibly a crash). The application itself has an integrated XMPP client which is able to send a message to the software manufacturer, informing him about the problems. At the same time the client engages a chat window where the user is connected to some XMPP based help chat. If no company staff is available, a message bot could be queried to provide generic answers and possibly point to other context sensitive help resources. All those different communication paths are controlled by the XMPP messaging technology. When specifying the XMPP standard, several key aspects drove the design process: Complete openness of the standard, any reference implementations and the ability to let anyone create a XMPP application free of charge

17 2.1 XMPP and Jingle 12 Any technologies used should be open and free. This mainly applies to the protocol characteristics, which are written in the Extensible Markup Language (XML). As XML is an open standard, it allows creating tools for editing, modeling, analyzing etc.. Interoperability with other IM systems should ensure that it is possible to incorporate other instant messaging technologies like ICQ [icq] or Microsoft Live Messenger [liv]. A simple protocol was of upmost importance. As we will soon discover, the XML dialect used in the XMPP specification is very human-readable friendly. It is easy to read and write, which simplifies the development process of both clients and servers. To support the creation of as many client applications as possible, ease of development of such clients is of an essence. Therefore as little responsibilities as possible should be burdened on the client. As the above example shows, the usual setup of an XMPP infrastructure involves a central server, which serves client connections. It is also possible to link several servers together to form a net of XMPP servers. A client is able to connect to a server via a login request. The server than allows access or denies it. In the next phase the server is able to accept message and to send these messages to the receiver. If the receiver is not available (for example offline) the message is stored and delivered as soon as the client becomes available. This concept is called store and forward. A similar situation occurs, when the receiver is not able to process the messages in a timely manner. The messages are queued on the server and sent when the receiver is ready. Since the messaging process is asynchronous, it is also possible to send an acknowledgement to the sender when the message has reached the receiver. The term message has been frequently used in the last paragraph. In fact there exist three 1 types of messages in the XMPP specification: <message />, <iq /> and <presence />. 1. <message /> The message element represents a conversational message. It is the type of text passed between users to exchange verbal information. Listing 2.1 shows such a message in the XML format. Listing 2.1. Usage of the message element 1 < message type =" normal " from =" com " 1 A fourth element named: <route/> exists but it is only used for server to server communication.

18 2.1 XMPP and Jingle 13 2 to=" com "> 3 <body > Never place friendship before profit. </ body > 4 </ message > The XML snippet describes a text message which is send from the sender john to the recipient sam. The text of the message is contained within the <body> element. Besides one-to-one text message several other types of messages exist, which are defined by the type attribute. The following table 2.1 describes the different types of messages. As can be seen, besides one-to-one communication, multi user chats are possible as well. Some special types of messages like error or headline messages are also supported. Quite interesting is the last entry in the table, supporting special kind of data via the jabber:x:oob type. This custom type is embedded in a special namespace, which can also be extended by clients to provide custom types. The concept is to embed information into messages, which should either be displayed differently or are not supposed to be displayed but rather provide metadata for special actions. Such an action could be to initiate a file transfer or to send information about another contact etc. Having seen what a simple text message looks like in listing 2.1, we turn to a more elaborate example described in listing 2.2. Listing 2.2. Sending a message to an XMPP multi-client chat session 1 < message type =" chat " from =" com " to=" com "> 2 <thread >01 </ thread > 3 <body > Never bluff a Klingon : </ body > 4 <x xmlns =" jabber :x: oob "> 5 <url > http :// www. kli. org / </ url > 6 <desc > The Klingon Language Institute </ desc > 7 </x> 8 </ message > In order to assign the message to a particular chat channel, the thread tag is used with a certain id. We can also see how the previously discussed special namespace is used in the x element. It describes an URL, which is attached to the message. It is up to the client implementation how to display this information to the user. This decoupling of the meta-information from the whole notion of the instant messaging makes XMPP a very powerful technology. Structured xml data can be transmitted in a transparent and asynchronous way. The lightweight proto-

19 2.1 XMPP and Jingle 14 col makes it ideal for thin clients and machines with limited resources or simply for processes, which need to efficiently transmit information. Message Type Description Regular Message normal like message (default) Chat chat One-on-one online chat Groupchat groupchat Online chatroom for multiple clients Headline headline A single catchline message Error error Message error Out-of-Band jabber:x:oob Meta-Information. Table 2.1. Different types of XMPP messages 2. <presence /> The presence element indicates the state of the client. This state is either user set or changed by the client application according to the interaction (or passiveness) of the client. Additionally to the effective state, other information regarding the condition of the client can be transmitted. When the client is not available it might be in a state of away. The state information can be complemented by the amount of time the client has been absent. Additionally a general message describing the state further can be attached to a presence message. Listing 2.3 shows a presence message with an attached special type. Listing 2.3. Announcing state via the presence element 1 < presence from =" com " to=" com "> 2 <show >away </ show > 3 < status > There is a customer born every minute. </ status > 4 < priority >1 </ priority > 5 <x xmlns =" jabber :x: delay " from =" com " 6 stamp =" T13 :13:04 " /> 7 </ presence > Besides the from and to attributes of the presence element, several child elements like show, status and priority provide information about the current situation. The x element is used with the custom namespace jabber:x:delay. With the attribute stamp, the element x is able to specify the time when the state of absenteeism started. 3. <iq /> The iq element transmits the control protocol of the XMPP technology. An IQ-based conversation uses the request/response paradigm, in that it sends an inquiry or a command and awaits a response. Because of the asynchronous nature of the XMPP protocol, the answer does not have to follow the

20 2.1 XMPP and Jingle 15 request immediately. This request/response model is called Info/Query (IQ). Figure 2.1 outlines this scenario. IQ-get (1) IQ-set (2) Entity 1 Entity 2 IQ-response (2) IQ-response (1) Fig IQ-Based Conversation As illustrated, an id is transmitted along with each message. The request initiator provides the id and the responder has to answer with the very same id. There is the possibility to set and get information via a request and to provide an appropriate answer. Getting is possible for static information, as well as to initiate a sequence of commands. Static information are items like time, client details, server information, search requests for users or chat groups etc.. Dynamic requests initiate a sequence of message exchanges. A good example for such a multi-phase iq is the register sequence for a new user. The client sends a register request, next the server answers with a set of details it requires from the client (usually login name and password), the clients sends those information and the server answers with an acknowledgement. Listing 2.4 demonstrates such a process. Listing 2.4. Register sequence on an XMPP server 1 SEND : <iq type =" get " id=" reg1 "> 2 <query xmlns =" jabber :iq: register "/> 3 </iq > 4 5 RECV : <iq type =" result " id=" reg1 "> 6 <query xmlns =" jabber :iq: register "> 7 < instructions > Choose a name and password to register. 8 </ instructions > 9 < username /> 10 < password /> 11 </ query >

21 2.1 XMPP and Jingle </iq > SEND : <iq type =" set " id=" reg2 "> 15 <query xmlns =" jabber :iq: register "> 16 <username > quark </ username > 17 <password > latinum </ password > 18 </ query > 19 </iq > RECV : <iq type =" result " id=" reg2 "/> The two ways communication model of the previous example illustrates how the id field is used to tie a response to a request. Additionally, the custom namespace jabber:iq:register is leveraged to describe the context of the conversation: the register process. From the previous examples it becomes obvious, where the advantages of XMPP technology over other instant messaging protocols are. The open nature of the specification, combined with the easy to read and comprehend XML syntax makes it a perfect match for many business scenarios. When taking into account, that most of today s internet protocols are transmitted via HTTP, the XMPP protocol could provide a viable alternative. Emerging technologies like XML-RPC or SOAP both use HTTP as their transport vehicle. With the flexible structure of XMPP, it is possible to transmit this kind of machine-made conversation as well. Automatically many problematic characteristics of the HTTP protocol, like the stateless nature of the connection, are avoided. Concluding, we immediately see the step-change increase in contextual richness, XML-RPC or SOAP interactivity becomes part of a wider, all-encompassing conversation between applications and humans. For further information about the XMPP technology, it is advised to study the appropriate specification documents [xmp], or to use one of the books listed in the appendix of this document. Highly recommended are the books Programming Jabber by D. J. Adams, 2002 [Ada02] or Instant Messaging in Java by Iain Shiegoka, 2002 [Shi02] XEP-0166: Jingle So far we have discussed the XMPP protocol mainly as a carrier for instant messaging applications. We will see now how the XMPP transport mechanisms can

22 2.1 XMPP and Jingle 17 be used to deliver other content types like voice or video chat, application sharing, file sharing, collaborative editing, whiteboarding etc.. To enable those features an extension to the XMPP protocol is introduced: the Jingle protocol as defined in XEP-0166 [xepa]. Although we have introduced Jingle as protocol to transmit voice data, it can basically be used for all the above scenarios. The job of Jingle is to initiate and manage peer-to-peer multimedia session, in a way which makes it interoperable with existing internet standards. Therefore we will now look at the steps necessary to establish such a session and how to use this session for voice data transmission. The Jingle standard uses common internet technologies like the UDP socket or the Real-time Transport Protocol [xepb] in a customized way to better interoperate with Jingle. While designing the Jingle protocol, the following items were treated with priority: Make it possible to manage a wide variety of peer-to-peer sessions (not limited to voice and video) within XMPP. Clearly separate the signaling channel (XMPP) from the data channel. Clearly separate the content description formats (e.g., for voice chat) from the content transport methods. Make it possible to add, modify, and remove content types from an existing session. Make it relatively easy to implement support for the protocol in standard XMPP clients. Where communication with non-xmpp entities is needed, push as much complexity as possible onto server-side gateways between the XMPP network and the non-xmpp network. To clarify the above points we have to take a closer look at the design of the Jingle protocol and how different aspects of transmissions are handled. With XMPP being the foundation of the protocol, it is assumed to have established a connection to an XMPP server. We can now use the <iq /> element to send Jingle specific signals to a remote user. Jingle is now responsible for: 1. Overall session management 2. Content description formats (the what ) 3. Content transport methods (the how ) A Jingle Session is composed of several different states as shown in figure 2.2. After the initial state, a session-initiate transition is invoked which performs

23 2.1 XMPP and Jingle 18 content-accept content-modify content-remove session-info transport-info content-accept content-modify content-remove session-info transport-info session-initiate Pending session-accept Active session-terminate session-terminate Fig Jingle session management several things at once. The initiator of the session sends a request to the receiver, containing information about the content description of the request and the means of transportation (see listing 2.5 for an example). What does that mean? A content description is defined as the format of the content type being send. It also formally declares the purpose of the session (e.g., voice or video ). This is the what of the session, such as the acceptable codecs when establishing a voice conversation. The transport method is the method for establishing data stream(s) between entities. Possible transports might include TCP, UDP, inband data, etc. This is the how of the session. The content transport method defines how to transfer bits from one host to another. Each transport method must specify whether it is lossy (thus suitable for applications where some packet loss is tolerable) or reliable (thus suitable for applications where packet loss is not tolerable). Listing 2.5. Initiating a Jingle session 1 <iq from =" com " to=" com " id="1" type =" set "> 2 < jingle xmlns =" http :// www. xmpp. org / extensions /xep html #ns" 3 action =" session - initiate " 4 initiator =" com " 5 sid =" a73sjjvkla37jfea " > 6 < content creator =" com " name =" audio - name "> 7 < description 8 xmlns =" http :// xmpp. org / extensions /xep html #ns"> </ description > 11 < transport xmlns =" http :// xmpp. org / extensions /xep html #ns"/> 12 </ content > </ jingle > 15 </iq >

24 2.1 XMPP and Jingle 19 Now being in the pending state, the initiator waits for a reaction of the receiver, who can either reject the request or accept it, thus moving the initiator in the active state. Reasons to reject the request can be: an unknown receiver, jingle not supported, no known content description or transport method or a malformed request. If none of these problems arose the receiver is able to agree on one content description (e.g. audio communication using the speex codec) and one means of transportation (e.g. using UDP on port 12345). The resulting answer contains those details and starts the audio communication. The nature of a content descriptions is defined in the XEP-0167 [xepb] specification, which relies on the IETF standard as defined in RFC 3551 [rfc]. A content description is called a payload. The following listing 2.6 shows such a content description with some common payload types. Each payload is defined by its own unique id according to RFC A similar set of informations is send to negotiate the transport mechanism. Listing 2.6. Possible payloads for a Jingle audio session 1 < description xmlns = http :// www. xmpp. org / extensions /xep html #ns > 2 <payload - type id= 96 name = speex clockrate = /> 3 <payload - type id= 97 name = speex clockrate = 8000 /> 4 <payload - type id= 18 name = G729 /> 5 <payload - type id= 103 name = L16 clockrate = channels = 2 /> 6 <payload - type id= 98 name = x- ISAC clockrate = 8000 /> 7 <payload - type id= 102 name = ilbc /> 8 <payload - type id= 4 name = G723 /> 9 <payload - type id= 0 name = PCMU clockrate = /> 10 <payload - type id= 8 name = PCMA /> 11 <payload - type id= 13 name = CN /> 12 </ description > To increase the flexibility, it is possible to change the content of the session during runtime. This allows to change the used protocol or to switch from voice to video chat. When in the pending or active state, it is also possible to transit into the stopping state terminating the ongoing session. During the course of a Jingle session, informational messages can also be exchanged to communicate the state of a participant. Possible elements to send within a <jingle /> parent element are <busy />, <hold />, <mute /> or <ringing />. With this fundamental overview of the Jingle specification, we have established a common nomenclature to use throughout this document. Although the Jingle technology is well designed and easy to comprehend, creating a custom implementation of the specification is well beyond the scope of this project. We will

25 2.1 XMPP and Jingle 20 therefore use the Smack API 3.0 [smaa] developed by Ignite Realtime [ign], which implements the Jingle specification as a Java library. A more in depth description can be found in chapter Smack API 3.0 The Smack API [smaa] is a Java library, complying with the XMPP standard. Since version 3.0 the Smack API also provides an implementation of the Jingle protocol. The development process of the library is following the open source paradigm although it is mostly governed and supported by its founding company: Ignite Realtime [ign]. Ignite Realtime is not only investing resources into the Smack API library but is also creating other products based on it and the XMPP technology in general. These other products encompass an XMPP server named Openfire server [ope], the Java based XMPP Instant Messaging client Spark [spa] and the Flash based XMPP library XIFF API [xif]. Besides the community edition of these products they also offer commercial extensions and support for the named applications. Special attention is paid to the Openfire server, which supports several advanced business features in its commercial offspring. We will now focus on the Smack API as it is used to incorporate the Jingle VoIP technology into the Eclipse Communication Framework. Some of the elaborate features of the Smack API are, that Smack is not only a set of wrapper classes for the XML messages, it provides a higher level of abstraction for elements like the contact roster (list of contacts) or a chat instance. It is not even required to interfere with the package level messaging. In fact it is not even required to be acquainted with XML, although it is helpful to do so. For simplified machine to machine communication, it is possible to simply set properties on a XMPP message or to attach entire Java objects. And finally, the Smack API is licensed under the Apache License [apa], which allows modification of the source base and free redistribution. These benefits sound very promising but are spoiled because of a dependency to the Java Media Framework (JMF) [jmf]. The JMF is required for the Voice over IP support, starting from Smack API version 3.0. According to the official JMF website: The Java Media Framework API (JMF) enables audio, video and other time-based media to be added to applications and applets built on Java technology. This optional package, which can capture, playback, stream, and

26 2.1 XMPP and Jingle 21 transcode multiple media formats, extends the Java 2 Platform, Standard Edition (J2SE) for multimedia developers by providing a powerful toolkit to develop scalable, cross-platform technology. Although this description is accurate, there are two major drawbacks in relying on the JMF. 1. To support the recording and playback on a specific platform, native code is required. This leads to the problem, that only a limited number of platforms are supported: Microsoft Windows 2000/XP, Linux and Solaris SPARC. Other platforms like MacOS or Windows Vista are not supported. 2. Adding to the above problem, further developments of the JMF seem to have been suspended. The latest release dates back to November It is therefore unlikely to see support for additional operating systems. The Smack API project is aware of these problems and is planning to remove the dependency on the JMF in favor of a custom solution. Since this is a rather ambitioned goal, no timeline has been established yet. To gain some more insights into the API structure of the Smack API, we will now examine a very simple example in listing 2.7, which establishes a connection to an XMPP server, spawns a chat instance and dispatches a simple chat message in this one-on-one chat. Behind the scene, this snippet exchanges some <iq /> messages to connect to server and to login after a successful connection. In the next phase the chat is created and a message is send using the <message /> elements. Listing 2.7. Simple Smack API usage 1 XMPPConnection connection = new XMPPConnection (" server. com "); 2 connection. connect (); 3 connection. login (" quark ", " latinum "); 4 5 Chat chat = connection. getchatmanager (). createchat (" server. com ", 6 new MessageListener () { 7 public void processmessage ( Chat chat, Message message ) { 8 System. out. println (" Received message : " + message ); 9 } 10 }); chat. sendmessage ("Hi Rom."); This example is pretty simple and could of course be more specifically configured, especially for the connection details. The XMPPConnection object plays an

27 2.1 XMPP and Jingle 22 important role in the Smack API as it is used to obtain several facilities to work in XMPP specific domains like the ChatManager. Other Routine steps to take would be to obtain the Roster, which contains the contacts of the logged in user. The Roster is also able provide extended information about the presence of individual contacts. Another important aspect of the Smack API is the ability to process incoming packages. Each message to the XMPP server from a client is called a packet and is sent as XML. The org.jivesoftware.smack.packet package contains classes that encapsulate the three different basic packet types allowed by XMPP (message, presence, and IQ). Classes such as Chat and Roster provide higher-level constructs that manage creating and sending packets automatically, but it is also possible to create and send packets directly. This fact, combined with the ability to extend the Smack API with custom extensions, makes it a very powerful API. Most of the functionality of the Smack API is built around this extension concept. A concept which works by defining hooks into the XMPP packet stream via namespaces. It is possible to get informed of events in known namespaces like jabber:iq:roster (e.g: play a sound file when somebody is coming online), or to provide hooks to a custom namespace. Taking the simple example of a time inquiry, listing 2.8 demonstrates how a defined hook intercepts the incoming package which is registered in the jabber:iq:time namespace. Listing 2.8. Custom extensions for an XMPP package 1 DEF : < smackproviders > 2 < iqprovider > 3 < elementname > query </ elementname > 4 <namespace > jabber :iq:time </ namespace > 5 <classname > org. jivesoftware. smack. packet.time </ classname > 6 </ iqprovider > 7 </ smackproviders > 8 9 PACKAGE : <iq type = result to= com 10 from = com id= time_1 > 11 <query xmlns = jabber :iq: time > 12 <utc > T17 :58:35 </ utc > 13 <tz >MDT </tz > 14 < display > Tue Sep 10 12: 58: </ display > 15 </ query > 16 </iq > The XML definition of the example is placed in the META-INF directory of the encompassing jar file. The provided classname element specifies a class within

28 2.1 XMPP and Jingle 23 that jar, which is invoked by introspection when such a time package arrives. The Smack API allows accessing the package data by pre-mapping it to appropriate data structures and by converting the values to Java specific data types. Additionally the Smack API offers the flexibility to define filters on incoming packages. Such filters can check the from, to or the id attributes, ongoing threads or namespaces etc.. They can also be combined, using Boolean logic, to further refine the results. A list of official extensions, already built into the Smack API, can be found on the Smack API website [smab]. We will now focus on the implementation of the Jingle specification inside the Smack API. So far we have seen how XMPP communication is performed and how the given features can be extended via the extension mechanism. To support Jingle, XMPP uses these two facilities. They key to establish a Jingle conference is an existing XMPPConnection instance. Listing 2.9 shows how this connection can be used to spawn a so called JingleManager. A JingleManager is responsible for the configuration and management of a Jingle session. Listing 2.9. Creating a Jingle session via the Smack API 1 ICETransportManager icetm = new ICETransportManager ( xmppconnection, 2 " stunserver. com ", 3478); 3 4 JmfMediaManager jmfmediamanager = new JmfMediaManager (); 5 6 j = new JingleManager ( xmppconnection, icetm, jmfmediamanager ); 7 j. addcreationlistener ( icetm0 ); 8 9 // listen for incoming calls 10 j. addjinglesessionrequestlistener ( new JingleSessionRequestListener () { 11 public void sessionrequested ( JingleSessionRequest request ) { 12 incoming = request. accept (); 13 incoming. start (); 14 } 15 }); // start call with a remote client 18 outgoing = j. createoutgoingjinglesession (" server. com "); 19 outgoing. start (); In line 1 of listing 2.9 we see how an ICETransportManager is instantiated. A transport managers job is to provide the connection details of the local machine (e.g.: the local ip, the port to use etc.). The Interactive Connectivity Establishment (ICE) [ice] transport manager is providing and managing out-of-band connections

29 2.1 XMPP and Jingle 24 between two XMPP entities, even if they are behind Network Address Translators (NATs) or firewalls. To accommodate this feature a middle negotiator called a STUN [stu] server is used. STUN is able to bridge through NATed networks and firewalls. In fact a STUNTransportManager can be used if desired. The advantage of the ICETransportManager is that it extends the STUN capabilities to fit exactly on the XMPP usage scenarios. Another transport manager provided is the BasicResolver. It scans for network devices and uses the first non-loopback address it finds. This very basic resolver is easy to use but not very flexible. More interesting is the BridgedTransportManager. This implementation is also able to bridge NATed networks but instead of relying on STUN, it uses the RTP technology to find available connections. To enable these facilities the XMPP server has to support these services. Finally, it is also possible to provide the connection details directly if they are known beforehand. In line 4 we see the instantiation of a JmfMediaManager. A media manager is responsible to provide and negotiate the encoding information of the media stream as well as to perform recording and playback of the audio data. So far the only media manager in existence is the JMF media manager. As explained earlier in this section, the Java Media Framework has some considerable drawbacks. It is therefore expected to see other implementations of the media manager in the future. In its current version, the JmfMediaManager supports the three audio codecs: gsm, g723 and PCMU (with khz). In line 6 we see how the transport manager, the media manager and the xmpp connection are finally brought together in one instance: the JingleManager. This central facility is the anchor point of the Jingle setup. It conjoins the two important factors: how and what of the audio transmission. We can use this configured facility to listen for incoming calls as shown in the following lines. A request listener is registered and its sessionrequest method is invoked as soon as a remote call is inbound. In a two step procedure the call is then accepted (or immediately rejected). In the end of the listing we see how an outgoing call is placed. It is as easy as to know the id of the remote contact. Only when the start method of a session object is called, is the recording or outputting of audio data started. Anything else beforehand is negotiated via <iq /> message on an XMPP package level. To sum up the Smack API features, it is necessary to mention a utility tool provided by the Smack library: the debugger client. This GUI tool is able to visualize the package traffic of an XMPP session. Included are two built-in debugging

30 2.2 Eclipse Communication Framework 25 consoles, which allow tracking all XML traffic between the client and the server. A lite debugger which is part of the smack.jar and an enhanced debugger contained in smackx-debug.jar. Figure 2.3 shows a screenshot of the advanced debugger. Fig Enhanced debugger of the Smack API library 2.2 Eclipse Communication Framework In chapter 1.3 we have seen what features characterize the Eclipse technology. We have investigated the plugin architecture as well as the core components of the Eclipse platform. We will now use this understanding to examine the Eclipse Communication Framework (ECF) [ecf]. The ECF is a set of plugins to support collaboration among individual software developers. This chapter will describe the architecture of the ECF project, what drives the design philosophy and how various object oriented patterns help to make the ECF a more versatile project. As VoIP integration into the Eclipse platform is of the main interest in this project, we will see how the ECF Call API is used to introduce a layer of abstraction to encompass various different VoIP protocols in section 3.1. Consolidation of development efforts is a key aspect of modern team management. The ECF is therefore striving to provide a set of extendable APIs, which

31 2.2 Eclipse Communication Framework 26 cover the most common communication channels in software development. Among these are instant messaging protocols, multi user chats, bulletin boards, shared editing, File Sharing, Voice over IP etc. All these different means of communication are covered in a technology independent approach by the ECF. Meaning the ECF is providing a higher level of abstraction to incorporate them into the Eclipse Platform, possibly with appropriate user interface elements. Taking the example of instant messaging, the ECF is able to provide support for various different protocols like ICQ, AIM, MSN or XMPP all under one UI. When looking at the wide field of shared editing, several different aspects are covered here. Sharing might affect a plain text editor or a more sophisticated Java Editor from the JDT project. Shared Editing is in fact focused on model sharing. There even exists a multi-user Sudoku game based on the ECF APIs. In order to merge all those different technologies under one unified framework, the ECF makes use of a so called lightweight communications container concept. The heart of such an architecture is formed by yet another core component, which acts as a central orchestrator for the various technologies. The concept relies on the two factors that, although technologically different, each communication family (e.g.: instant messaging) has some common characteristics and that those features can be abstracted into one all encompassing interface. The ECF is therefore providing APIs for the most common tasks: Identity Unambiguous identification of a user Sharedobject Sharing data information Datashare Channels for message exchange Discovery Finding users Filetransfer Transfering data in a peer-to-peer manner Presence Keeping track of the state of other users Remote service Interfacing with remote entities Telephony Placing Voice or Video over IP calls User interface Abstraction of various aspects of communication An implementer of a communication technology is therefore inclined to make use of several of these APIs. Such an implementation is than referred to as a provider to the ECF.

32 2.2 Eclipse Communication Framework Lightweight Container Architecture Because of the pluggable nature of eclipse and the ECF, such a provider is embedded into one or more plugins. To incorporate these plugins into the ECF, the lightweight communications container concept is used. It is referred to as lightweight because of its flexible and immaculate nature. A container is merely a vehicle to be embedded into the Eclipse Communication Framework. To construct such a container, it is required to make use of the base interface IContainer. This interface provides methods to connect and disconnect to its intended peer. It is also possible to register listeners on the container, to be informed of events like creation, disposal, connection or disconnection. The instantiation of an IContainer happens via an IContainerInstantiator. This factory interface is registered in the plugin.xml file of its parent plugin via the extension point org.eclipse.ecf.containerfactory. Listing 2.10 shows such a declaration for an XMPP implementation. Listing Registering an XMPP container instantiator 1 < extension point =" org. eclipse. ecf. containerfactory "> 2 < containerfactory 3 class =" org. eclipse. ecf. provider. xmpp. XMPPContainerInstantiator " 4 description =" XMPP ( Jabber )" 5 name =" ecf. xmpp. smack "> 6 </ containerfactory > 7 </ extension > This extension allows plugins to register themselves as providers of ECF containers. The declared IContainerInstantiator is aware of a list of IContainer instances it is able to provide. Plugins using this extension point can define a new implementation of any desired communications protocol, and expose that protocol as an instance of an IContainer. When a physical instance of an IContainer is to be instantiated, the ContainerFactory is used. This factory is aware of all registered instantiators. When client requests are made to the ContainerFactory to create IContainer instances, those requests will be re-directed to the given IContainerInstantiator, which spawns such an IContainer. Figure 2.4 visualizes these relationships. The advantage of such a two-tier architecture lies within the flexibility to support various connection driven features of communicaton technologies. It is possible to provide connectivity for messages, file transfer or VoIP (for an XMPP example) from one instantiator. Each data channel is contained within its own IContainer,

33 2.2 Eclipse Communication Framework 28 plugin.xml Plugin Registry <extension point="org.eclipse.ecf.containerfactory"> <containerfactory class="xmppcontainerinstantiator">... Declared Aware ContainerFactory Queries XMPPContainerInstantiator Requests XMPPContainer Instantiates XMPPContainer Fig ECF Container Architecture which share some common configuration characteristics inherited from the instantiator Adaptable Container Another key feature of the Eclipse Platform is the ability to extend an IContainers capabilities during runtime. A common scenario for such an occurrence is an Instant Messaging protocol like XMPP for example. The IContainer is implemented as an XMPPContainer, which exposes connectivity and presence features of the XMPP protocol. To provide the features of a chat session within the constraints of the XMPP protocol, it is required that the container is aware of the semantics to initiate a chat session. A reason for not supporting those characteristics might be a special dialect on the server or a third party library that does not support chatrooms or does not comply with the official standards. In either case it is intended to extend the ground functionality of the XMPPContainer with some additional abilities. For such a scenario the so called adapter pattern is used. The pattern is originally described in the famous book Design Pattern by the

34 2.2 Eclipse Communication Framework 29 Gang of Four [EGV95]. A more comprehensive example targeted on the Eclipse Platform can be found on the Eclipse Zone website [ada]. The adapter patern is an object oriented pattern, which allows extending the functionality of a component during runtime, without using introspection, runtime weaving or any other binary modification. Figure 2.5 illustrates the concept of the adapter pattern in form of an UML diagram. Fig Adaptable pattern As we can see, the client wants to work with an empowered version of the BaseClass. In order to add the additional functionality to the BaseClass, we do not want to (or cannot) change its characteristics. We therefore make use of a so called AdapterFactory. The AdapaterFactory is responsible for creating an empowered version of the BaseClass. The usual approach here is to pass the instance of the BaseClass and an unrealized version of the EmpoweredClass (e.g.: a Class definition) to the AdapterFactory. The factory is aware of the instances it can produce (e.g.: EmpoweredClass) and can now make some checks to see if it is able to merge these two entities. Usually this happens by instantiating the EmpoweredClass and passing the BaseClass instance to it as a reference. The client receives an instance of the BaseClass wrapped in an even more powerful EmpoweredClass. The EmpoweredClass propably exposes the contained BaseClass via a convenience method but also makes use of it itself, by providing additional functionality. The main advantage of this procedure is that we have

35 2.2 Eclipse Communication Framework 30 enriched the abilities of the BaseClass without any interference with its code base. The added functionality has been solely attached during runtime. In Eclipse terminology this pattern has been adapted (no pun intended) by introducing the concept of extension points to register the AdapterFactory in a global scope. While the factory is already loaded on plugin startup, the clients wanting to make use of it does not have to be aware of a particular AdapaterFactory, which is responsible for the merge operation at hands. The global IAdapterManager is able to determine a suitable factory at runtime (if one is registered). We will see how this pattern is applied to the XMPP provider when additional Jingle functionallity is added in chapter Namespaces and IDs In the ECF, identity of local or remote entities such as users, remote services, and groups are all represented via the ID interface. This interface provides the basic contract for addressing uniquely identified entities. ID instances belong to a given Namespace. Namespaces define the range of allowable values of the ID instances belonging to that Namespace. For example, the namespace of XMPP user identities is defined by XMPP RFC3920 [xmp] as having the following structure: jid = [ node ] domain [ "/" resource ] Only IDs which comply with this rule can be treated as XMPP ids (jid = jabber id). Other communications protocols and their associated service identities have their own Namespaces (e.g.: ftp, http, sip, irc, etc.), each with their own requirements for addressing and identity. The ID contract is not bound to any specific protocol. It makes it possible to create client applications that are insensitive to the addressing differences between protocols while still guaranteeing basic uniqueness requirements within a given namespace. An ID is bound to a specific usage scenario (protocol) but is free to float around in the applications context. To ensure the uniqueness of an ID, it is for one bound to a certain namespace and secondly composed by a central instance of that namespace. In order to introduce a namespace to the ECF universe, the extension point org.eclipse.ecf.namespace is used (see listing 2.12). Listing Registering an XMPP namespace 1 < extension point =" org. eclipse. ecf. namespace "> 2 < namespace

36 2.2 Eclipse Communication Framework 31 3 class =" org. eclipse. ecf. provider. xmpp. identity. XMPPNamespace " 4 description =" XMPP Namespace " 5 name =" ecf. xmpp "/> 6 </ extension > The previous listing assigns the name ecf.xmpp to the class XMPPNamespace. The XMPPNamespace class provides the XMPP namespace implementation and as described above implements the XMPP namespace restrictions. It is also responsible for constructing new ID instances via the ECF IDFactory. To construct an instance of and XMPPID, a client could use the following code: Listing Obtaining an XMPPID from an XMPP namespace 1 IDFactory idf = IDFactory. getdefault (); 2 XMPPID xmppid = ( XMPPID ) idf. createid (" ecf. xmpp ", " com "); This code goes through several steps by first looking up the ecf.xmpp namespace in the eclipse extension registry. Next the createinstance() method on the XMPPNamespace instance is invoked, which manufactures an ID element. This XMPPID is then returned to the client.

37 3 Integrating Jingle into the ECF This chapter will focus on the integration of the Jingle Voice over IP technology into the Eclipse Communication Framework (ECF). We will see how the Smack API is leveraged to map its functionality onto the ECF interfaces. In previous chapters a description has been given regarding the components which define the Instant Messaging technology XMPP and how its different elements act together to support message exchange in multiple ways. Following this introduction, we have seen how a VoIP specification like Jingle can be superimposed on the XMPP communication model to extend its capabilities. We are also aware of the Eclipse Platform with its various features and extension based development model. One of these additions is the ECF, which provides means to improve collaboration of multiple developers. In the following section the main goal is to describe an approach to bring all those different aspects together under the belt of the Eclipse Platform. 3.1 Call API As described in chapter 2.2, several aspects in the ECF are supported by specific APIs. There are interfaces for identity management, file transfers, discovery etc.. One of those APIs deals with the notion of telephony, both in terms of audio and video communication. The API for audio transmissions is entitled Call API and is a central part of this project. The Call API is responsible of providing a layer of abstraction for a particular VoIP technology. This abstracted implementation can then be integrated into the Eclipse user interface or into a standalone Eclipse RCP application. It is therefore essential to broaden the scope of this API, so that every VoIP implementation is supported no matter how different their design philosophy might be.

38 3.2 Design of the Jingle Provider 33 The Call API is momentarily in a state of change. Its foundation has been laid out but it is not a stable API yet. Over the course of this project, several changes have been introduced to the API to gain increased stability and flexibility by supporting various usages scenarios. It is most likely, that the API will continue to change as more and more VoIP implementations are supported. Since the Call API is a layer of abstraction, it is pluggable into a user interface no matter what VoIP implementation is running under the hood. Due to the immature nature of the Call API, its graphical counter part the Call UI is very much underdeveloped. Throughout the progress of this project, several preliminary user interface elements have been developed to provide basic functionality within the Eclipse workbench. A fully revised planned out set of APIs for the UI will be developed in the future. Currently only one provider for the Call API exists: a Skype provider [skya]. This provider requires having the original Skype client running alongside of the Eclipse/ECF instance. The Call API interfaces with the Skype client to place calls or to get informed of incoming events. Therefore it is not a fully standalone Call API provider. The Jingle provider, which will be developed here, will be fully integrated (except the native JMF libraries). In the following sections we will explore the Call API and provide an appropriate Jingle based implementation. The ultimate goal is to create an ECF provider, that can be used in the Eclipse workbench to place and receive calls. 3.2 Design of the Jingle Provider To get started with the implementation efforts, we have to get an overview of the components already in existence, as some of those elements might provide required functionality. In fact the ECF is already supporting the XMPP Instant Messaging protocol by providing messaging and group chats. Therefore the connection facilities for an XMPP connection are already developed and can be reused in the efforts to integrate the Jingle protocol. On top of the connection infrastructure, several user interface elements exist, which display a contact roster and contact sensitive details. These elements can also be used by the Jingle provider. In order to understand the interrelationships of the Jingle provider with the surrounding Eclipse infrastructure, we will now explore the various components, which are used by the Jingle provider. The diagram in figure 3.1 highlights the directly related plugins. As we can see, the org.eclipse.ecf.provider.jingle

39 3.2 Design of the Jingle Provider 34 is the root plugin of the Jingle provider. Based on this plugin, two other related plugins are of most importance: the org.eclipse.ecf.provider.xmpp and the org.jivesoftware.smack plugin. The smack plugin is housing the Smack API in version 3.0 in its source code form. It is not making use of any Eclipse related properties but is merely exposing its APIs as a plugin. Alongside the source code, several binary libraries are also contained in the Smack API plugin. These include libraries for STUN, JMF interfacing and codecs like Speex. The second important plugin for the Jingle provider, the XMPP provider, is also making heavy use of the Smack API plugin. For the purpose of Jingle integration, it was required to upgrade the Smack API to version 3.0 (previously 2.0). This step enforced several modifications in the code base of the XMPP provider. Although it is technically possible to have two plugins with the same id in the same Eclipse Platform instance (when they can be distinguished by their version number), it is not possible to integrate the XMPP provider into the Jingle provider when they use different instances (versions) of the Smack API plugin. The Java classloader mechanism does not recognize these two Smack API instances as compatible. Consequently the XMPP provider has been branched in the source code repository and is maintained separately until the Smack API 3.0 based XMPP provider is considered stable enough to be merged with the main development stream. Fig Plugin dependencies of the Jingle provider The reason why the two formerly mentioned plugins are so important is because of their ability to provide a concrete implementation of business logic. Most other plugins, directly referenced by the Jingle provider, do only specify interfaces and abstract implementations or utility functionality. Of course these plugins also