Voice over IP in the Eclipse Communication Framework

Size: px
Start display at page:

Download "Voice over IP in the Eclipse Communication Framework"

Transcription

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. name@server.com). 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 =" quark@domain. 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=" rom@domain. 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 =" quark@domain. com " to=" rom@domain. 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 =" quark@domain. com " to=" rom@domain. 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 =" quark@domain. 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 =" quark@server. com " to=" rom@server. com " id="1" type =" set "> 2 < jingle xmlns =" http :// www. xmpp. org / extensions /xep html #ns" 3 action =" session - initiate " 4 initiator =" quark@server. com " 5 sid =" a73sjjvkla37jfea " > 6 < content creator =" quark@server. 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 (" rom@ 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= rom@server. com 10 from = quark@server. 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 (" rom@ 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 ", " quark@server. 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

An Introduction to VoIP Protocols

An Introduction to VoIP Protocols An Introduction to VoIP Protocols www.netqos.com Voice over IP (VoIP) offers the vision of a converged network carrying multiple types of traffic (voice, video, and data, to name a few). To carry out this

More information

Access to This Tutorial. What is XMPP. Ozgur Ozturk's Introduction to XMPP 1

Access to This Tutorial. What is XMPP. Ozgur Ozturk's Introduction to XMPP 1 XMPP Protocol and Application Development using Open Source XMPP Software and Libraries Ozgur Ozturk ozturk@gatech.edu Georgia Institute of Technology, Atlanta, GA Acknowledgement: This tutorial is based

More information

FRAFOS GmbH Windscheidstr. 18 Ahoi 10627 Berlin Germany info@frafos.com www.frafos.com

FRAFOS GmbH Windscheidstr. 18 Ahoi 10627 Berlin Germany info@frafos.com www.frafos.com WebRTC for Service Providers FRAFOS GmbH FRAFOS GmbH Windscheidstr. 18 Ahoi 10627 Berlin Germany info@frafos.com www.frafos.com This document is copyright of FRAFOS GmbH. Duplication or propagation or

More information

Receiving the IP packets Decoding of the packets Digital-to-analog conversion which reproduces the original voice stream

Receiving the IP packets Decoding of the packets Digital-to-analog conversion which reproduces the original voice stream Article VoIP Introduction Internet telephony refers to communications services voice, fax, SMS, and/or voice-messaging applications that are transported via the internet, rather than the public switched

More information

Software Engineering 4C03 VoIP: The Next Telecommunication Frontier

Software Engineering 4C03 VoIP: The Next Telecommunication Frontier Software Engineering 4C03 VoIP: The Next Telecommunication Frontier Rudy Muslim 0057347 McMaster University Computing and Software Department Hamilton, Ontario Canada Introduction Voice over Internet Protocol

More information

FRAFOS GmbH Windscheidstr. 18 Ahoi 10627 Berlin Germany info@frafos.com www.frafos.com

FRAFOS GmbH Windscheidstr. 18 Ahoi 10627 Berlin Germany info@frafos.com www.frafos.com WebRTC for the Enterprise FRAFOS GmbH FRAFOS GmbH Windscheidstr. 18 Ahoi 10627 Berlin Germany info@frafos.com www.frafos.com This document is copyright of FRAFOS GmbH. Duplication or propagation or extracts

More information

Dissertation Title: SOCKS5-based Firewall Support For UDP-based Application. Author: Fung, King Pong

Dissertation Title: SOCKS5-based Firewall Support For UDP-based Application. Author: Fung, King Pong Dissertation Title: SOCKS5-based Firewall Support For UDP-based Application Author: Fung, King Pong MSc in Information Technology The Hong Kong Polytechnic University June 1999 i Abstract Abstract of dissertation

More information

Encapsulating Voice in IP Packets

Encapsulating Voice in IP Packets Encapsulating Voice in IP Packets Major VoIP Protocols This topic defines the major VoIP protocols and matches them with the seven layers of the OSI model. Major VoIP Protocols 15 The major VoIP protocols

More information

District of Columbia Courts Attachment 1 Video Conference Bridge Infrastructure Equipment Performance Specification

District of Columbia Courts Attachment 1 Video Conference Bridge Infrastructure Equipment Performance Specification 1.1 Multipoint Control Unit (MCU) A. The MCU shall be capable of supporting (20) continuous presence HD Video Ports at 720P/30Hz resolution and (40) continuous presence ports at 480P/30Hz resolution. B.

More information

A Comparative Study of Signalling Protocols Used In VoIP

A Comparative Study of Signalling Protocols Used In VoIP A Comparative Study of Signalling Protocols Used In VoIP Suman Lasrado *1, Noel Gonsalves *2 Asst. Prof, Dept. of MCA, AIMIT, St. Aloysius College (Autonomous), Mangalore, Karnataka, India Student, Dept.

More information

This document specifies the software requirements of CrossTalk+ A VoIP softphone. It describes the specifications of all components of CrossTalk.

This document specifies the software requirements of CrossTalk+ A VoIP softphone. It describes the specifications of all components of CrossTalk. 1. Introduction CrossTalk+ is a VoIP (Voice over IP) softphone which lets you call anywhere in the world at nominal rates. CrossChat the chat component of CrossTalk enables you to chat with people speaking

More information

Project Code: SPBX. Project Advisor : Aftab Alam. Project Team: Umair Ashraf 03-1853 (Team Lead) Imran Bashir 02-1658 Khadija Akram 04-0080

Project Code: SPBX. Project Advisor : Aftab Alam. Project Team: Umair Ashraf 03-1853 (Team Lead) Imran Bashir 02-1658 Khadija Akram 04-0080 Test Cases Document VOIP SOFT PBX Project Code: SPBX Project Advisor : Aftab Alam Project Team: Umair Ashraf 03-1853 (Team Lead) Imran Bashir 02-1658 Khadija Akram 04-0080 Submission Date:23-11-2007 SPBX

More information

To ensure you successfully install Timico VoIP for Business you must follow the steps in sequence:

To ensure you successfully install Timico VoIP for Business you must follow the steps in sequence: To ensure you successfully install Timico VoIP for Business you must follow the steps in sequence: Firewall Settings - you may need to check with your technical department Step 1 Install Hardware Step

More information

Voice and Video over Wireless LAN

Voice and Video over Wireless LAN International Journal of Scientific and Research Publications, Volume 3, Issue 9, September 2013 1 Voice and Video over Wireless LAN Akshay Iyer*, Akshay Badgujar*, Maheshkumar Eaga*, Rohit Iyer* *B.E

More information

Connect your Control Desk to the SIP world

Connect your Control Desk to the SIP world Connect your Control Desk to the SIP world Systems in

More information

White paper. SIP An introduction

White paper. SIP An introduction White paper An introduction Table of contents 1 Introducing 3 2 How does it work? 3 3 Inside a normal call 4 4 DTMF sending commands in sip calls 6 5 Complex environments and higher security 6 6 Summary

More information

Marratech Technology Whitepaper

Marratech Technology Whitepaper Marratech Technology Whitepaper Marratech s technology builds on many years of focused R&D and key reference deployments. It has evolved into a market leading platform for Real Time Collaboration (RTC)

More information

CrossTalk is a VoIP (Voice over IP) softphone which lets you call anywhere in the world at nominal rates.

CrossTalk is a VoIP (Voice over IP) softphone which lets you call anywhere in the world at nominal rates. 1. Introduction CrossTalk is a VoIP (Voice over IP) softphone which lets you call anywhere in the world at nominal rates. 1.1 Purpose This document specifies the software requirements of CrossTalk v1.04

More information

Internet Technology Voice over IP

Internet Technology Voice over IP Internet Technology Voice over IP Peter Gradwell BT Advert from 1980s Page 2 http://www.youtube.com/v/o0h65_pag04 Welcome to Gradwell Gradwell provides technology for every line on your business card Every

More information

Manual. ABTO Software

Manual. ABTO Software Manual July, 2011 Flash SIP SDK Manual ABTO Software TABLE OF CONTENTS INTRODUCTION... 3 TECHNICAL BACKGROUND... 6 QUICK START GUIDE... 7 FEATURES OF FLASH SIP SDK... 10 2 INTRODUCTION Trends indicate

More information

VOICE OVER IP AND NETWORK CONVERGENCE

VOICE OVER IP AND NETWORK CONVERGENCE POZNAN UNIVE RSITY OF TE CHNOLOGY ACADE MIC JOURNALS No 80 Electrical Engineering 2014 Assaid O. SHAROUN* VOICE OVER IP AND NETWORK CONVERGENCE As the IP network was primarily designed to carry data, it

More information

Implementing SIP and H.323 Signalling as Web Services

Implementing SIP and H.323 Signalling as Web Services Implementing SIP and H.323 Signalling as Web Services Ge Zhang, Markus Hillenbrand University of Kaiserslautern, Department of Computer Science, Postfach 3049, 67653 Kaiserslautern, Germany {gezhang, hillenbr}@informatik.uni-kl.de

More information

ACD: Average Call Duration is the average duration of the calls routed bya a VoIP provider. It is a quality parameter given by the VoIP providers.

ACD: Average Call Duration is the average duration of the calls routed bya a VoIP provider. It is a quality parameter given by the VoIP providers. ACD: Average Call Duration is the average duration of the calls routed bya a VoIP provider. It is a quality parameter given by the VoIP providers. API: An application programming interface (API) is a source

More information

SHORT DESCRIPTION OF THE PROJECT...3 INTRODUCTION...4 MOTIVATION...4 Session Initiation Protocol (SIP)...5 Java Media Framework (JMF)...

SHORT DESCRIPTION OF THE PROJECT...3 INTRODUCTION...4 MOTIVATION...4 Session Initiation Protocol (SIP)...5 Java Media Framework (JMF)... VoIP Conference Server Evgeny Erlihman jenia.erlihman@gmail.com Roman Nassimov roman.nass@gmail.com Supervisor Edward Bortnikov ebortnik@tx.technion.ac.il Software Systems Lab Department of Electrical

More information

Mobile VoIP: Managing, scheduling and refining voice packets to and from mobile phones

Mobile VoIP: Managing, scheduling and refining voice packets to and from mobile phones Mobile VoIP: Managing, scheduling and refining voice packets to and from mobile phones MOHAMMAD ABDUS SALAM Student ID: 01201023 TAPAN BISWAS Student ID: 01201003 \ Department of Computer Science and Engineering

More information

Voice over IP. Presentation Outline. Objectives

Voice over IP. Presentation Outline. Objectives Voice over IP Professor Richard Harris Presentation Outline Brief overview of VoIP and applications Challenges of VoIP IP Support for Voice Protocols used for VoIP (current views) RTP RTCP RSVP H.323 Semester

More information

Design, implementation and analysis of a large scale audio conferencing system using SIP

Design, implementation and analysis of a large scale audio conferencing system using SIP Design, implementation and analysis of a large scale audio conferencing system using SIP A n t ó n i o V a r a n d a & T i a g o L o u r e i r o Master of Science Thesis Stockholm, Sweden 2006 ECS/ICT-2006-07

More information

Goal We want to know. Introduction. What is VoIP? Carrier Grade VoIP. What is Meant by Carrier-Grade? What is Meant by VoIP? Why VoIP?

Goal We want to know. Introduction. What is VoIP? Carrier Grade VoIP. What is Meant by Carrier-Grade? What is Meant by VoIP? Why VoIP? Goal We want to know Introduction What is Meant by Carrier-Grade? What is Meant by VoIP? Why VoIP? VoIP Challenges 2 Carrier Grade VoIP Carrier grade Extremely high availability 99.999% reliability (high

More information

Integrate VoIP with your existing network

Integrate VoIP with your existing network Integrate VoIP with your existing network As organisations increasingly recognise and require the benefits voice over Internet Protocol (VoIP) offers, they stop asking "Why?" and start asking "How?". A

More information

By Kundan Singh Oct 2010. Communication

By Kundan Singh Oct 2010. Communication Flash Player Audio Video Communication By Kundan Singh Oct 2010 Modern multimedia communication systems have roots in several different technologies: transporting video over phone lines, using multicast

More information

Need for Signaling and Call Control

Need for Signaling and Call Control Need for Signaling and Call Control VoIP Signaling In a traditional voice network, call establishment, progress, and termination are managed by interpreting and propagating signals. Transporting voice

More information

A Web Services Framework for Collaboration and Audio/Videoconferencing

A Web Services Framework for Collaboration and Audio/Videoconferencing A Web Services Framework for Collaboration and Audio/Videoconferencing Geoffrey Fox, Wenjun Wu, Ahmet Uyar, Hasan Bulut Community Grid Computing Laboratory, Indiana University gcf@indiana.edu, wewu@indiana.edu,

More information

TECHNICAL CHALLENGES OF VoIP BYPASS

TECHNICAL CHALLENGES OF VoIP BYPASS TECHNICAL CHALLENGES OF VoIP BYPASS Presented by Monica Cultrera VP Software Development Bitek International Inc 23 rd TELELCOMMUNICATION CONFERENCE Agenda 1. Defining VoIP What is VoIP? How to establish

More information

4. H.323 Components. VOIP, Version 1.6e T.O.P. BusinessInteractive GmbH Page 1 of 19

4. H.323 Components. VOIP, Version 1.6e T.O.P. BusinessInteractive GmbH Page 1 of 19 4. H.323 Components VOIP, Version 1.6e T.O.P. BusinessInteractive GmbH Page 1 of 19 4.1 H.323 Terminals (1/2)...3 4.1 H.323 Terminals (2/2)...4 4.1.1 The software IP phone (1/2)...5 4.1.1 The software

More information

Voice over IP is Transforming Business Communications

Voice over IP is Transforming Business Communications White Paper Voice over IP is Transforming Business Communications Voice over IP (VoIP) is changing the world of telecommunications. It entails the transmission of voice calls over data networks that support

More information

Whitepaper: Microsoft Office Communications Server 2007 R2 and Cisco Unified Communications Manager Integration Options

Whitepaper: Microsoft Office Communications Server 2007 R2 and Cisco Unified Communications Manager Integration Options Whitepaper: Microsoft Office Communications Server 2007 R2 and Cisco Unified Communications Manager Integration Options Document Summary This document provides information on several integration scenarios

More information

How To Understand The Differences Between A Fax And A Fax On A G3 Network

How To Understand The Differences Between A Fax And A Fax On A G3 Network The Fax on IP Networks White Paper February 2011 2 The Fax on IP Networks Contents Overview... 3 Group 3 Fax Technology... 4 G.711 Fax Pass-Through... 5 T.38 IP Fax Relay... 6 Network Design Considerations...

More information

presentation Our customers & Partners AE40 www.ae40.com +972-9-743-8410

presentation Our customers & Partners AE40 www.ae40.com +972-9-743-8410 AE40 presentation AE40 Our customers & Partners AE40 profile AE40 founded at 2002 Privately held company VoIP and Video over IP based communication solutions(radio, intercom, public announcements, telephony,

More information

Overview of Voice Over Internet Protocol

Overview of Voice Over Internet Protocol Overview of Voice Over Internet Protocol Purva R. Rajkotia, Samsung Electronics November 4,2004 Overview of Voice Over Internet Protocol Presentation Outline History of VoIP What is VoIP? Components of

More information

Software-Powered VoIP

Software-Powered VoIP Software-Powered VoIP Ali Rohani Anthony Murphy Scott Stubberfield Unified Communications Architecture Core Scenarios UC endpoints QOE Monitoring Archiving CDR AOL Public IM Clouds Yahoo Remote Users MSN

More information

Session Initiation Protocol (SIP) The Emerging System in IP Telephony

Session Initiation Protocol (SIP) The Emerging System in IP Telephony Session Initiation Protocol (SIP) The Emerging System in IP Telephony Introduction Session Initiation Protocol (SIP) is an application layer control protocol that can establish, modify and terminate multimedia

More information

ZyXEL V100 Support Notes. ZyXEL V100. (V100 Softphone 1 Runtime License) Support Notes

ZyXEL V100 Support Notes. ZyXEL V100. (V100 Softphone 1 Runtime License) Support Notes ZyXEL V100 (V100 Softphone 1 Runtime License) Support Notes Version 1.00 April 2009 1 Contents Overview 1. Overview of V100 Softphone...3 2. Setting up the V100 Softphone.....4 3. V100 Basic Phone Usage.....7

More information

VoIP Conferencing. The latest in IP technologies deliver the next level of service innovation for better meetings. Global Collaboration Services

VoIP Conferencing. The latest in IP technologies deliver the next level of service innovation for better meetings. Global Collaboration Services Global Collaboration Services VoIP Conferencing The latest in IP technologies deliver the next level of service innovation for better meetings. ENERGIZE YOUR CONNECTIONS Table of Contents > > Contents...

More information

point to point and point to multi point calls over IP

point to point and point to multi point calls over IP Helsinki University of Technology Department of Electrical and Communications Engineering Jarkko Kneckt point to point and point to multi point calls over IP Helsinki 27.11.2001 Supervisor: Instructor:

More information

internet technologies and standards

internet technologies and standards Institute of Telecommunications Warsaw University of Technology 2015 internet technologies and standards Piotr Gajowniczek Andrzej Bąk Michał Jarociński multimedia in the Internet Voice-over-IP multimedia

More information

WebRTC: Why and How? FRAFOS GmbH. FRAFOS GmbH Windscheidstr. 18 Ahoi 10627 Berlin Germany info@frafos.com www.frafos.com

WebRTC: Why and How? FRAFOS GmbH. FRAFOS GmbH Windscheidstr. 18 Ahoi 10627 Berlin Germany info@frafos.com www.frafos.com WebRTC: Why and How? FRAFOS GmbH FRAFOS GmbH Windscheidstr. 18 Ahoi 10627 Berlin Germany info@frafos.com www.frafos.com This docume nt is copyright of FRAFOS GmbH. Duplication or propagation or e xtracts

More information

Voice over IP Basics for IT Technicians

Voice over IP Basics for IT Technicians Voice over IP Basics for IT Technicians White Paper Executive summary The IP phone is coming or has arrived on desk near you. The IP phone is not a PC, but does have a number of hardware and software elements

More information

Glossary of Terms and Acronyms for Videoconferencing

Glossary of Terms and Acronyms for Videoconferencing Glossary of Terms and Acronyms for Videoconferencing Compiled by Irene L. Ferro, CSA III Education Technology Services Conferencing Services Algorithm an algorithm is a specified, usually mathematical

More information

Network Connection Considerations for Microsoft Response Point 1.0 Service Pack 2

Network Connection Considerations for Microsoft Response Point 1.0 Service Pack 2 Network Connection Considerations for Microsoft Response Point 1.0 Service Pack 2 Updated: February 2009 Microsoft Response Point is a small-business phone solution that is designed to be easy to use and

More information

Alkit Reflex RTP reflector/mixer

Alkit Reflex RTP reflector/mixer Alkit Reflex RTP reflector/mixer Mathias Johanson, Ph.D. Alkit Communications Introduction Real time audio and video communication over IP networks is attracting a lot of interest for applications like

More information

Measure wireless network performance using testing tool iperf

Measure wireless network performance using testing tool iperf Measure wireless network performance using testing tool iperf By Lisa Phifer, SearchNetworking.com Many companies are upgrading their wireless networks to 802.11n for better throughput, reach, and reliability,

More information

159.334 Computer Networks. Voice over IP (VoIP) Professor Richard Harris School of Engineering and Advanced Technology (SEAT)

159.334 Computer Networks. Voice over IP (VoIP) Professor Richard Harris School of Engineering and Advanced Technology (SEAT) Voice over IP (VoIP) Professor Richard Harris School of Engineering and Advanced Technology (SEAT) Presentation Outline Basic IP phone set up The SIP protocol Computer Networks - 1/2 Learning Objectives

More information

SIP : Session Initiation Protocol

SIP : Session Initiation Protocol : Session Initiation Protocol EFORT http://www.efort.com (Session Initiation Protocol) as defined in IETF RFC 3261 is a multimedia signaling protocol used for multimedia session establishment, modification

More information

Java Application Development using Eclipse. Jezz Kelway kelwayj@uk.ibm.com Java Technology Centre, z/os Service IBM Hursley Park Labs, United Kingdom

Java Application Development using Eclipse. Jezz Kelway kelwayj@uk.ibm.com Java Technology Centre, z/os Service IBM Hursley Park Labs, United Kingdom 8358 Java Application Development using Eclipse Jezz Kelway kelwayj@uk.ibm.com Java Technology Centre, z/os Service IBM Hursley Park Labs, United Kingdom Abstract Learn how to use the powerful features

More information

Web Conferencing: It should be easy THE REASONS WHY IT IS NOT AND THE PATHS TO OVERCOME THE CHALLENGES.

Web Conferencing: It should be easy THE REASONS WHY IT IS NOT AND THE PATHS TO OVERCOME THE CHALLENGES. September 2013 Daitan White Paper Web Conferencing: It should be easy THE REASONS WHY IT IS NOT AND THE PATHS TO OVERCOME THE CHALLENGES. Highly Reliable Software Development Services http://www.daitangroup.com/webconferencing

More information

Voice over IP (VoIP) Overview. Introduction. David Feiner ACN 2004. Introduction VoIP & QoS H.323 SIP Comparison of H.323 and SIP Examples

Voice over IP (VoIP) Overview. Introduction. David Feiner ACN 2004. Introduction VoIP & QoS H.323 SIP Comparison of H.323 and SIP Examples Voice over IP (VoIP) David Feiner ACN 2004 Overview Introduction VoIP & QoS H.323 SIP Comparison of H.323 and SIP Examples Introduction Voice Calls are transmitted over Packet Switched Network instead

More information

Integrating Voice over IP services in IPv4 and IPv6 networks

Integrating Voice over IP services in IPv4 and IPv6 networks ARTICLE Integrating Voice over IP services in IPv4 and IPv6 networks Lambros Lambrinos Dept.of Communication and Internet studies Cyprus University of Technology Limassol 3603, Cyprus lambros.lambrinos@cut.ac.cy

More information

CONNECTING TO LYNC/SKYPE FOR BUSINESS OVER THE INTERNET NETWORK PREP GUIDE

CONNECTING TO LYNC/SKYPE FOR BUSINESS OVER THE INTERNET NETWORK PREP GUIDE CONNECTING TO LYNC/SKYPE FOR BUSINESS OVER THE INTERNET NETWORK PREP GUIDE Engineering Version 1.3 June 3, 2015 Table of Contents Foreword... 3 Current Network... 4 Understanding Usage/Personas... 4 Modeling/Personas...

More information

Quality Estimation for Streamed VoIP Services

Quality Estimation for Streamed VoIP Services Quality Estimation for Streamed VoIP Services Mousa Al-Akhras and Hussein Zedan STRL, De Montfort University, Leicester, UK makhras@dmu.ac.uk, hzedan@dmu.ac.uk http://www.cse.dmu.ac.uk/strl/index.html

More information

What's New in Sametime 8.5. Roberto Chiabra IBM Certified IT Specialist

What's New in Sametime 8.5. Roberto Chiabra IBM Certified IT Specialist What's New in Sametime 8.5 Roberto Chiabra IBM Certified IT Specialist What's new in Sametime 8.5 Sametime Connect Client Online Meetings Audio / Video W eb Browser Clients & W eb 2.0 APIs Sametime Systems

More information

On-Demand Call Center with VMware View

On-Demand Call Center with VMware View On-Demand Call Center with VMware A VMware 5 and Mitel Unified Communication Practice KEY BENEFITS Leverage infrastructure consolidation and desktop virtualization to deliver instant call center architecture.

More information

IP-Telephony Real-Time & Multimedia Protocols

IP-Telephony Real-Time & Multimedia Protocols IP-Telephony Real-Time & Multimedia Protocols Bernard Hammer Siemens AG, Munich Siemens AG 2001 1 Presentation Outline Media Transport RTP Stream Control RTCP RTSP Stream Description SDP 2 Real-Time Protocol

More information

MINIMUM NETWORK REQUIREMENTS 1. REQUIREMENTS SUMMARY... 1

MINIMUM NETWORK REQUIREMENTS 1. REQUIREMENTS SUMMARY... 1 Table of Contents 1. REQUIREMENTS SUMMARY... 1 2. REQUIREMENTS DETAIL... 2 2.1 DHCP SERVER... 2 2.2 DNS SERVER... 2 2.3 FIREWALLS... 3 2.4 NETWORK ADDRESS TRANSLATION... 4 2.5 APPLICATION LAYER GATEWAY...

More information

Voice over IP & Other Multimedia Protocols. SIP: Session Initiation Protocol. IETF service vision. Advanced Networking

Voice over IP & Other Multimedia Protocols. SIP: Session Initiation Protocol. IETF service vision. Advanced Networking Advanced Networking Voice over IP & Other Multimedia Protocols Renato Lo Cigno SIP: Session Initiation Protocol Defined by IETF RFC 2543 (first release march 1999) many other RFCs... see IETF site and

More information

EarthLink Business SIP Trunking. ININ IC3 IP PBX Customer Configuration Guide

EarthLink Business SIP Trunking. ININ IC3 IP PBX Customer Configuration Guide EarthLink Business SIP Trunking ININ IC3 IP PBX Customer Configuration Guide Publication History First Release: Version 1.0 August 30, 2011 CHANGE HISTORY Version Date Change Details Changed By 1.0 8/30/2011

More information

A Tool for Evaluation and Optimization of Web Application Performance

A Tool for Evaluation and Optimization of Web Application Performance A Tool for Evaluation and Optimization of Web Application Performance Tomáš Černý 1 cernyto3@fel.cvut.cz Michael J. Donahoo 2 jeff_donahoo@baylor.edu Abstract: One of the main goals of web application

More information

FOR COMPANIES THAT WANT TO EXPAND AND IMPROVE THEIR TELEPHONE SYSTEM

FOR COMPANIES THAT WANT TO EXPAND AND IMPROVE THEIR TELEPHONE SYSTEM IP PBX VH-500 FOR COMPANIES THAT WANT TO EXPAND AND IMPROVE THEIR TELEPHONE SYSTEM IP PBX VH-500 The Virtual IP PBX VH-500 is an unified communication system hosted in the cloud, and it's an excellent

More information

Key Elements of a Successful SIP Device Provisioning System

Key Elements of a Successful SIP Device Provisioning System Key Elements of a Successful SIP Device Provisioning System A white paper by Incognito Software April, 2006 2006 Incognito Software Inc. All rights reserved. Page 1 of 6 Key Elements of a Successful SIP

More information

PANDORA FMS NETWORK DEVICE MONITORING

PANDORA FMS NETWORK DEVICE MONITORING NETWORK DEVICE MONITORING pag. 2 INTRODUCTION This document aims to explain how Pandora FMS is able to monitor all network devices available on the marke such as Routers, Switches, Modems, Access points,

More information

Developing and Integrating Java Based SIP Client at Srce

Developing and Integrating Java Based SIP Client at Srce Developing and Integrating Java Based SIP Client at Srce Davor Jovanovi and Danijel Matek University Computing Centre, Zagreb, Croatia Davor.Jovanovic@srce.hr, Danijel.Matek@srce.hr Abstract. In order

More information

Configuration Notes 290

Configuration Notes 290 Configuring Mediatrix 41xx FXS Gateway with the Asterisk IP PBX System June 22, 2011 Proprietary 2011 Media5 Corporation Table of Contents Introduction... 3 About Mediatrix 41xx Series FXS Gateways...

More information

IBM Rational Web Developer for WebSphere Software Version 6.0

IBM Rational Web Developer for WebSphere Software Version 6.0 Rapidly build, test and deploy Web, Web services and Java applications with an IDE that is easy to learn and use IBM Rational Web Developer for WebSphere Software Version 6.0 Highlights Accelerate Web,

More information

PortGo 6.0 for Wndows User Guide

PortGo 6.0 for Wndows User Guide PortGo 6.0 for Wndows User Guide PortSIP Solutions, Inc. sales@portsip.com http:// @May 20, 2010 PortSIP Solutions, Inc. All rights reserved. This User guide for PortGo Softphone 6.0. 1 Table of Contents

More information

Combining Voice over IP with Policy-Based Quality of Service

Combining Voice over IP with Policy-Based Quality of Service TechBrief Extreme Networks Introduction Combining Voice over IP with Policy-Based Quality of Service Businesses have traditionally maintained separate voice and data networks. A key reason for this is

More information

SIP Forum Fax Over IP Task Group Problem Statement

SIP Forum Fax Over IP Task Group Problem Statement T.38: related to SIP/SDP Negotiation While the T.38 protocol, approved by the ITU-T in 1998, was designed to allow fax machines and computer-based fax to carry forward in a transitioning communications

More information

ABC SBC: Securing the PBX. FRAFOS GmbH

ABC SBC: Securing the PBX. FRAFOS GmbH ABC SBC: Securing the PBX FRAFOS GmbH Introduction A widely reported fraud scenarios is the case of a malicious user detecting the address of a company s PBX and accessing that PBX directly. Once the attacker

More information

NAT TCP SIP ALG Support

NAT TCP SIP ALG Support The feature allows embedded messages of the Session Initiation Protocol (SIP) passing through a device that is configured with Network Address Translation (NAT) to be translated and encoded back to the

More information

ATA: An Analogue Telephone Adapter is used to connect a standard telephone to a high-speed modem to facilitate VoIP and/or calls over the Internet.

ATA: An Analogue Telephone Adapter is used to connect a standard telephone to a high-speed modem to facilitate VoIP and/or calls over the Internet. KEY VOIP TERMS 1 ACD: Automatic Call Distribution is a system used to determine how incoming calls are routed. When the ACD system receives an incoming call it follows user-defined specifications as to

More information

CTX OVERVIEW. Ucentrik CTX

CTX OVERVIEW. Ucentrik CTX CTX FACT SHEET CTX OVERVIEW CTX SDK API enables Independent Developers, VAR s & Systems Integrators and Enterprise Developer Teams to freely and openly integrate real-time audio, video and collaboration

More information

Advanced Networking Voice over IP: RTP/RTCP The transport layer

Advanced Networking Voice over IP: RTP/RTCP The transport layer Advanced Networking Voice over IP: RTP/RTCP The transport layer Renato Lo Cigno Requirements For Real-Time Transmission Need to emulate conventional telephone system Isochronous output timing same with

More information

Peer to Peer Search Engine and Collaboration Platform Based on JXTA Protocol

Peer to Peer Search Engine and Collaboration Platform Based on JXTA Protocol Peer to Peer Search Engine and Collaboration Platform Based on JXTA Protocol Andraž Jere, Marko Meža, Boštjan Marušič, Štefan Dobravec, Tomaž Finkšt, Jurij F. Tasič Faculty of Electrical Engineering Tržaška

More information

Introducing Cisco Voice and Unified Communications Administration Volume 1

Introducing Cisco Voice and Unified Communications Administration Volume 1 Introducing Cisco Voice and Unified Communications Administration Volume 1 Course Introduction Overview Learner Skills and Knowledge Course Goal and Course Flow Additional Cisco Glossary of Terms Your

More information

The user interface of SIPPS is fully skinnable

The user interface of SIPPS is fully skinnable - THE ULTIMATE SOFTWARE TELEPHONE - SIPPS : Voice over IP for everybody SIPPS is a professional Voice over IP client software SIPPS is fully SIP-compliant Fully customizable softphone The user interface

More information

VoIP Solutions Guide Everything You Need to Know

VoIP Solutions Guide Everything You Need to Know VoIP Solutions Guide Everything You Need to Know Simplify, Save, Scale VoIP: The Next Generation Phone Service Ready to Adopt VoIP? 10 Things You Need to Know 1. What are my phone system options? Simplify,

More information

Voice over Internet Protocol (VoIP) systems can be built up in numerous forms and these systems include mobile units, conferencing units and

Voice over Internet Protocol (VoIP) systems can be built up in numerous forms and these systems include mobile units, conferencing units and 1.1 Background Voice over Internet Protocol (VoIP) is a technology that allows users to make telephone calls using a broadband Internet connection instead of an analog phone line. VoIP holds great promise

More information

ABC SBC: Mobile Subscriber Support. FRAFOS GmbH

ABC SBC: Mobile Subscriber Support. FRAFOS GmbH ABC SBC: Mobile Subscriber Support FRAFOS GmbH Introduction Applications supporting mobile VoIP are such as Viper or Skype increasingly becoming the default communication means for mobile users. Affordable

More information

Application Notes for Avaya IP Office 7.0 Integration with Skype Connect R2.0 Issue 1.0

Application Notes for Avaya IP Office 7.0 Integration with Skype Connect R2.0 Issue 1.0 Avaya Solution & Interoperability Test Lab Application Notes for Avaya IP Office 7.0 Integration with Skype Connect R2.0 Issue 1.0 Abstract These Application Notes describe the steps to configure an Avaya

More information

Voice over IP (VoIP) Basics for IT Technicians

Voice over IP (VoIP) Basics for IT Technicians Voice over IP (VoIP) Basics for IT Technicians VoIP brings a new environment to the network technician that requires expanded knowledge and tools to deploy and troubleshoot IP phones. This paper provides

More information

Mobicents 2.0 The Open Source Communication Platform. DERUELLE Jean JBoss, by Red Hat 138

Mobicents 2.0 The Open Source Communication Platform. DERUELLE Jean JBoss, by Red Hat 138 Mobicents 2.0 The Open Source Communication Platform DERUELLE Jean JBoss, by Red Hat 138 AGENDA > VoIP Introduction > VoIP Basics > Mobicents 2.0 Overview SIP Servlets Server JAIN SLEE Server Media Server

More information

This specification this document to get an official version of this User Network Interface Specification

This specification this document to get an official version of this User Network Interface Specification This specification describes the situation of the Proximus network and services. It will be subject to modifications for corrections or when the network or the services will be modified. Please take into

More information

Voice over IP: RTP/RTCP The transport layer

Voice over IP: RTP/RTCP The transport layer Advanced Networking Voice over IP: /RTCP The transport layer Renato Lo Cigno Requirements For Real-Time Transmission Need to emulate conventional telephone system Isochronous output timing same with input

More information

Guidance Regarding Skype and Other P2P VoIP Solutions

Guidance Regarding Skype and Other P2P VoIP Solutions Guidance Regarding Skype and Other P2P VoIP Solutions Ver. 1.1 June 2012 Guidance Regarding Skype and Other P2P VoIP Solutions Scope This paper relates to the use of peer-to-peer (P2P) VoIP protocols,

More information

VoipSwitch softphones

VoipSwitch softphones VoipSwitch softphones sales@voipswitch.com 3/21/2011 Voiceserve ltd.grosvenor House,1 High Street,London United Kingdom 1 Contents Introduction and solution overview... 2 iphone mobile softphone... 3 Google

More information

Session Initiation Protocol and Services

Session Initiation Protocol and Services Session Initiation Protocol and Services Harish Gokul Govindaraju School of Electrical Engineering, KTH Royal Institute of Technology, Haninge, Stockholm, Sweden Abstract This paper discusses about the

More information

ETM System SIP Trunk Support Technical Discussion

ETM System SIP Trunk Support Technical Discussion ETM System SIP Trunk Support Technical Discussion Release 6.0 A product brief from SecureLogix Corporation Rev C SIP Trunk Support in the ETM System v6.0 Introduction Today s voice networks are rife with

More information

IP Telephony Deployment Models

IP Telephony Deployment Models CHAPTER 2 Sections in this chapter address the following topics: Single Site, page 2-1 Multisite Implementation with Distributed Call Processing, page 2-3 Design Considerations for Section 508 Conformance,

More information

b+s Connects CCE Edition

b+s Connects CCE Edition b+s Connects CCE Edition A Business Whitepaper by Bucher + Suter May, 2014 Todd Samalin, Sales Engineer Contents General Introduction... 2 What is b+s Connects?... 2 b+s Connects Introduction... 2 Editions...

More information

Basic Vulnerability Issues for SIP Security

Basic Vulnerability Issues for SIP Security Introduction Basic Vulnerability Issues for SIP Security By Mark Collier Chief Technology Officer SecureLogix Corporation mark.collier@securelogix.com The Session Initiation Protocol (SIP) is the future

More information

Short messaging solutions, including XMPP based instant messaging and text based conferences, between health care providers and general practitioners

Short messaging solutions, including XMPP based instant messaging and text based conferences, between health care providers and general practitioners Short messaging solutions, including XMPP based instant messaging and text based conferences, between health care providers and general practitioners Sokol Dhana One of the most challenging problems in

More information

Synchronization Essentials of VoIP WHITE PAPER

Synchronization Essentials of VoIP WHITE PAPER Synchronization Essentials of VoIP WHITE PAPER Synchronization Essentials of VoIP Introduction As we accelerate into the New World of VoIP we assume we can leave some of the trappings of wireline telecom

More information