ROMANO LAYOUT
7/21/11
12:26 PM
Page 36
TOPICS IN DESIGN AND IMPLEMENTATION
Meetecho Mobile: Accessing an IETF-Compliant Conferencing Framework from Cellular Devices Alessandro Amirante, Tobia Castaldi, and Lorenzo Miniero, Meetecho Simon Pietro Romano, University of Napoli Federico II
ABSTRACT In this article we present Meetecho Mobile, an innovative conferencing client designed for mobile devices. Such a client provides access to conferences compliant with the most recent standard proposals currently under definition within the IETF. It allows mobile users to participate in multimedia conferences involving, besides an XMPP-based chat, both audio and video streams. The article discusses the design and implementation of the conferencing client and highlights the most notable solutions we devised in order to effectively handle a whole suite of protocols, ranging from signaling (SIP/SDP, XMPP) to real-time streaming (RTP). We also provide information about the main performance figures characterizing the client’s behavior.
CONTEXT AND MOTIVATION Multimedia conferencing has lately attracted interest from the international research community, due to the many challenges it entails in both the control and data planes. Within the Internet Engineering Task Force (IETF), work on conferencing was originally carried out within the SIPPING Working Group (WG) [1], whose purpose was to document how Session Initiation Protocol (SIP) could be used to implement rich multimedia applications. Afterward, the XCON [2] working group was chartered in order to define protocols, data models, and interfaces for the management of centralized conferences. XCON’s main milestones have been met ([2–4]), and the remaining work is on the right track toward successful completion. Meanwhile, a proposal to extend XCON toward a distributed scenario [5] has been formulated by the authors of this article. Indeed, we are active contributors in all of the above cited groups and have since long worked on pioneering implementations of the proposed standards, which have proven helpful in the definition, evaluation, and refinement of the involved protocols, as well as in the description of so-called best common practices (BCPs) associated with their utilization.
36
0163-6804/11/$25.00 © 2011 IEEE
The main outcome of the mentioned efforts has been the creation of an innovative real-time collaboration framework called Meetecho [6], which involves most of the newly defined mechanisms and protocols, thus also acting as a playground for the assessment of the proposed functionality, as well as for its potential refinement. Meetecho currently supports the following functions: • Extensible Messaging and Presence Protocol (XMPP)-based real-time chat • Mixed audio and video streaming • Whiteboard • Remote desktop sharing • Presentation sharing • Moderation based on Binary Floor Control Protocol (BFCP) [3] • Session recording • Conference control and manipulation based on Centralized Conferencing Manipulation Protocol (CCMP) [4] Lately, a consistent part of our efforts has been devoted to enabling access to the Meetecho platform from cellular devices. Hence, herein we present Meetecho Mobile, a conferencing client designed for mobile devices. Although not supporting all of the functions mentioned for the fully-fledged client running on desktop computers, Meetecho Mobile allows mobile users to participate in multimedia conferences involving, besides an XMPP-based chat, both audio and video streams. It currently supports full-duplex audio streaming, together with passive reception of the mixed video stream (no support is currently available for real-time capture and transmission of video generated at the mobile device itself). Support for moderation has been introduced as well, while there is no support for CCMP as of yet. The remainder of the article is organized as follows. We present some related work. We discuss the main requirements that have to be guaranteed by any mobile conferencing client wishing to access a Meetecho-enabled conference. We then move to the design of the mobile client, whose implementation is detailed, which focuses on the most challenging issues we faced in order
IEEE Communications Magazine • August 2011
ROMANO LAYOUT
7/21/11
12:26 PM
Page 37
to enable support for a wide suite of protocols, ranging from signaling (SIP/SDP, XMPP) to real-time streaming (RTP). We provide information about the main performance figures characterizing the client’s behavior. Finally, we conclude the article by summarizing the main achievements while also presenting directions of our future work.
RELATED WORK As multimedia communications over the Internet have become very popular, a number of solutions have been developed to access such functionality from mobile devices. Here we focus on the solutions suitable for devices equipped with either the Symbian or Android OS, since they represent the two reference platforms we present in the implementation section of the article. A mobile version of the Skype software is available, allowing Skype users to place VoIP calls, chat, and share files. As to the VoIP functionality, it allows audio flows to be transmitted, and support for video was introduced in early 2011. Audio streams are carried through a proprietary protocol and encoded in a proprietary format. Furthermore, there is no possibility to set up a conference call involving more than two participants. Fring is a mobile peer-to-peer Internet telephony network enabling users to talk and chat using ICQ, Google Talk, Windows Live Messenger, AIM, Yahoo Messenger, and SIP providers. It supports two-way video calls (within the Fring network), while multi-user conference calls are not yet available. Fring used to offer support for Skype, too, but this feature was recently removed due to the large load impact it was having on Skype servers. Even if none of the software solutions presented above is actually a conferencing client, they nonetheless represent useful terms of comparison if one is interested in evaluating the performance related to VoIP functionality, as we show later.
MEETECHO MOBILE: PROTOCOL REQUIREMENTS To build a client capable to interact with a standard XCON conferencing framework, a number of requirements have to be taken into account. There are a number of protocols that have to be necessarily implemented on the client’s side. First, since our solution uses instant messaging as an orchestrating technology, the client has to provide support for XMPP [7]. This is justified by the need to manage buddy lists, as well as to enable instant messaging communication. XMPP can also be exploited as a basic conference control protocol, allowing the client to: • Retrieve information about conferences and conference participants • Start the process of joining a conference In the control plane, support for SIP is also required. SIP is in fact the most suitable choice when it comes to setting up multimedia sessions among the many clients involved in a conference.
IEEE Communications Magazine • August 2011
It is worth spending a few words on the debate currently ongoing about SIP vs. XMPP. The former has been originally conceived for session setup purposes, while the latter has been thought for IM and presence. Nevertheless, the development of extensions to both protocols made their scopes overlap, so that SIP can be exploited for instant messaging, whereas XMPP is also suitable for call signaling. We decided to adopt both protocols for their native purposes, thus fostering interoperability with both legacy SIP and XMPP clients. Coming to the data plane, once a session has been successfully established, the conferencing client has to support: • Real-time audio and video streaming with the Real-Time Transport Protocol (RTP) • Encoding/decoding of audio and video streams, in both reception and transmission All of the mentioned requirements are effectively supported in our mobile client, except for the capability to send video through RTP. This last point represents one of the subjects of our current work and is further discussed in the remarks that conclude this article.
The architecture we devised is compliant with the three-tier approach, whereby an application is divided into three interoperating layers dedicated, respectively, to the graphical user interface, the business logic, and the management of back-end data structures. Such layers interact on the basis of a clientserver paradigm.
DESIGN As anticipated before, the mobile client has to be able to: • Manage XMPP-based communications with the server • Establish SIP sessions negotiated via SDP • Send and receive RTP packets • Encode and decode voice data • Decode video data • Handle moderation Also, NAT-traversal issues should also be taken into account. Interactions among a mobile user, the Meetecho client and the conference focus are illustrated in the sequence diagram in Fig. 1. Indeed, the architecture we devised is compliant with the three-tier approach, whereby an application is divided in three inter-operating layers dedicated, respectively, to the graphical user interface, to the business logic and to the management of back-end data structures. Such layers interact on the basis of a client-server paradigm (the GUI is a client of the business logic, which is in turn client of the data management layer). This is achieved through the definition of interfaces. The business logic layer can be considered as the main engine of the application and it can in turn be designed following different architectural models. In this paragraph we deal with the design of the mobile conferencing client engine,1 for which we adopted a two-tier model, comprising the following two levels (Fig. 2): • The first level provides all functional requirements (login, participation in a conference, etc.). It is made of a single module, called DConengine, acting as an interface toward the application layer above. • The second level looks after operational requirements and is divided into the following independent modules: –XMPP engine: a presence and chat module –SIP/SDP engine: a session setup and management module
1
For the sake of brevity, we skip the details associated with the design of the graphical user interface, which, in the case of handheld devices, has its own peculiarities and challenges.
37
ROMANO LAYOUT
7/21/11
12:26 PM
Page 38
We remark that the RTPEngine we
Meetecho focus
Meetecho mobile
realized handles audio and video
: Mobile user
1 : Login()
streams in different
2 : Notify presence via XMPP()
ways. In fact, we borrowed from Java Media Framework a clustering technique for audio packets
3 : Send buddy and conference list via XMPP() 4 : Select conference()
which avoids an 5 : Join conference via SIP/SDP()
annoying screeching effect due to transmission delays.
6 : RTP-based media streaming() 7 : RTP-based media streaming() 8 : Leave conference() 9 : Logout from conference via SIP() 10 : Logout from system() 11 : Cancel presence via XMPP()
Figure 1. High-level sequence diagram illustrating interactions among a mobile user, Meetecho mobile and the Meetecho conference focus. –RTP engine: a real-time streaming module –Audio engine: dedicated to the management of audio streams –Video engine: dedicated to the management of video streams –BFCP engine: dedicated to moderation aspects –NAT engine: dedicated to NAT-traversal Intermodule communication can happen just through vertical interactions, on the basis of the well-known Observer/Observable design pattern. Such a pattern is often used when there is a need to keep the state of a number of independent objects under control and can be fruitfully employed as an architectural basis for a generic event management system.
IMPLEMENTATION In this section we present how we implemented the designed conferencing client on both a Symbian OS architecture and on an Android system.
IMPLEMENTATION CHOICES Symbian — Among the numerous development platforms available for the Symbian OS, we chose the S60 SDK, in one of its most recent editions (the fifth). As to the programming lan-
38
guage, we had two main options available: • Java micro edition • C++ for Symbian We made a thorough comparison between the two application programming interfaces (APIs) available and realized that the best option, in our case, was C++, since it covers almost 80 percent of the functionality needed at the client (which is much more than the corresponding set of functions available in Java). We realized the main client engine as a dynamic link library (DLL), so as to provide a general-purpose conferencing module also exploitable by applications other than our Meetecho mobile client. Android — For what concerns Android, we relied on its official SDK and used Java, which is the official programming language for Android devices. To strike the balance between functionality and interoperability, we developed our application for version 1.6 of the firmware, which, despite the increased functions of 2.1- and 2.2based devices, is still one of the most deployed in the Android market. The Android implementation was realized as a standalone application.
IEEE Communications Magazine • August 2011
ROMANO LAYOUT
7/21/11
12:26 PM
Page 39
XMPP Symbian — The S60 fifth edition framework does not natively provide an implementation of XMPP . Nonetheless, it allows programmers to embed code written in C or C++. Hence, we chose to use the code developed within the open source project named Iksemel, which makes available a porting for Symbian. The mentioned Iksemel code has been ported to the Symbian S60 environment and made available as a DLL, which has been used as a basis for the development of the presence module of the mobile client. Android — While the first versions of Android provided an XMPP stack, latest versions (including 1.6) removed such a native support for the protocol. We hence looked for a viable solution and found the asmack protocol stack, which is an open source Android port of the well known Smack stack we had already used for our desktop application. We implemented XMPP as an Android service and configured all our Activities as listeners of XMPP events to let them become aware of the current state of the sessions.
SIP/SDP Symbian — The SIP module, including all parts associated with SDP-based session negotiations, has been built on top of a rich API available for the S60 framework and providing functions needed for registering clients, negotiating sessions through SDP, resolving URIs, sending high level messages destined to VoIP applications. Android — For what concerns SIP/SDP, we looked for a valid Java implementation that could be somehow re-used in the Android SDK. Considering our desktop client application uses the well-known MjSIP stack, we looked for Android ports of the library, and discovered the SipDroid project, which provides an open source SIP client for Android devices, and is actually based on a modified version of MjSIP. We exploited such work in our client, by removing unneeded features, at the same time adding support for re-INVITEs.
RTP Symbian — Like the SIP/SDP module, also the RTPEngine has been built on top of the base classes provided by the S60 framework, and provides all functionality needed when dealing with RTP transmissions. We remark that the RTPEngine we realized handles audio and video streams in different ways. In fact, we borrowed from Java Media Framework a clustering technique for audio packets that avoids an annoying screeching effect due to transmission delays: we first buffer four RTP packets and immediately thereafter send them all together as a single burst. Each packet contains a 20 ms audio sample; hence, the first transmission happens with a delay of 80 ms. From this instant on, we alternate buffering periods (during which the next four samples are accumulated) with burst transmission periods. The two activities iterate with a period of about
IEEE Communications Magazine • August 2011
DConEngine
XMPP engine
SIP/SDP engine
RTP engine
Audio engine
Video engine
BFCP engine
NAT engine
Figure 2. Client’s engine architecture. 80 ms. With this approach, we can emulate a behavior in which, on average, four 20-ms-long audio samples are transmitted every 80 ms, which is exactly the expected behavior of a regular audio source. By appropriately using the timestamp field of the RTP header of the transmitted samples, we are able to reconstruct the correct time sequence at the receiver. Android — On Android, RTP support has been deployed in two different ways: • For audio, we relied on the functions already provided by SipDroid. • For video, we used an open source Java RTP stack called jrtp, which did not need any modification in order to work on Android. In both cases we also added a way to put a call on hold and to dynamically limit RTP channels to a single direction (e.g., for users only interested in listening to a conference) in order not to waste bandwidth that might be paid for.
AUDIO ENCODING/DECODING Symbian — The S60 SDK makes available the Audio Streaming API for audio management, which offers specific interfaces toward the lowlevel controller of the multimedia framework (MMF) for Symbian OS. Hence, we exploited it in a straightforward way to implement the AudioEngine, by sending/receiving audio data to/from the MMF in an incremental fashion. In this case, the codec employed was G.711. Android — As already anticipated, for audio we relied on the SipDroid library. We used the GSM audio codec, which gave us a good tradeoff between voice quality and bandwidth consumption. Speakerphone support was also based on SipDroid.
VIDEO ENCODING/DECODING The implementation of the video engine definitely represents the most challenging task we had to face and for which we still have some important open issues. As already said, our work currently lacks the capability of sending video. Hence, the issue of how to encode video frames is not addressed in this article. On the other hand, video decoding can be performed either by exploiting the hardware decoder available on the device, or through software. Although the former approach might seem more attractive, we embraced the software approach because a hardware decoder for the desired format is not always available on the device.
39
ROMANO LAYOUT
7/21/11
12:26 PM
Work still has to be done before consid-
Page 40
In the following we describe how we implemented a video software decoder. We chose the H.263 codec as the Meetecho server provides users with H.263-encoded video streams.
ering this effort complete. First, we have to enable video transmission from the device. The challenge resides in the capability to effectively capture video from the embedded device camera.
Symbian — The video engine implements a finite state machine cyclically evolving among three different states, loading, decoding, and bitmapping, the last two of which are executed in threads that are separated from the rest of the application, since the processes of decoding and bitmap construction are both CPU-bound and take resources away from the other application activities. By using separated threads having low execution priority, we forced the application to dedicate to them just the processor idle times. Android — Video support on Android was also challenging. In fact, while the Android SDK provides efficient APIs to access and process both incoming and outgoing audio streams, this is only partially true when it comes to video. The SDK provides a native H.263 codec, but there is no way to exploit it with streams: the only way to access it is through the MediaPlayer API, which only supports Real-Time Streaming Protocol (RTSP) streams, and cannot be used with RTP. We hence devised a software H.263 decoder, which forced us to cope with video RTP streams ourselves (through jrtp). As a final step, we implemented a custom view for the presentation of the decoded frames.
MODERATION Symbian — Rather than implementing the client side of the Binary Floor Control Protocol (BFCP), we provided our framework with a server-side dual tone multifrequency (DTMF) interface to the floor control server. We realized basic moderation functionality (i.e., floor request/release) through DTMF tones carried within RTP packets. Android — Besides the mentioned DTMF interface, on Android we also implemented the BFCP client through the same Java library already available for the Meetecho desktop client.
NAT-TRAVERSAL
USING A REAL ANDROID DEVICE
Several NAT traversal techniques have been standardized, the most effective one being the Interactive Connectivity Establishment (ICE) protocol [8]. ICE leverages the use of STUN and TURN in order to circumvent NAT elements placed along the communication path. For our purposes, instead we chose to rely on a server-side approach to NAT traversal, exploiting an RTP proxy. This is reasonable in XCON since media packets always flow through the conference focus; hence, RTP proxying will not introduce any further delay.
With Android, two different issues arose: • No tool we are aware of allows users to make video calls on Android systems. • Even Skype, which does support audio communications, performed really badly on the real device. This last issue is already known to the Skype community, as witnessed by several posts on Skype’s forum, and seems to depend on the specific device we used. Hence, in this subsection we limit ourselves to providing the figures characterizing the behavior of Meetecho mobile. Bandwidth consumption was exactly the same as with Symbian in both the audio-only and audiovideo scenarios, which is straightforward since we adopted the same codecs. On the other hand, the mean CPU level was around 10 percent when only audio is involved, reaching 50 percent when video reception is involved, too. This last result shows how the software decoder we realized allows us to receive H.263-encoded video
EXPERIMENTAL CAMPAIGN In this section we present the results of the trials we conducted to show how Meetecho mobile compares to the clients introduced earlier.
USING A REAL SYMBIAN DEVICE To have an estimation of the performance of our software on the real device, we used the Energy
40
Profiler, an application allowing power consumption and several other parameters to be tracked on S60 devices. With this application running in the background, we placed a call with Skype (which, we recall, only supports audio calls), and evaluated resource consumption in terms of CPU load, power, current, and bandwidth. We compared such parameters with the figures resulting from Meetecho mobile while accessing an audio-only conference. Figure 3a shows how Skype took up, on average, around 43 percent of the CPU, while Meetecho mobile used around 26 percent. Figures 3b and 3c show that power and current consumptions were pretty much the same, while Figs. 3d and 3e show that our bandwidth occupation levels were around 13 kbytes/s (downstream) and 10 kbytes/s (upstream), against the 5 kbytes/s (downstream) and 2.5 kbytes/s (upstream) generated by Skype. Both the CPU and bandwidth level results can be explained by recalling that Meetecho mobile employs the G.711 format for encoding the audio flows, which is known to be bandwidth intensive while taking few CPU cycles for the encoding/decoding operations. To assess the performance of our client when video streams are involved, we repeated the same experimental campaign comparing the figures resulting from the Fring software while making a video call, and Meetecho mobile while participating in a videoconference. Figure 4a shows how, in both cases, adding video functionality brought the CPU level of the real device to around 100 percent. Figures 4b and 4c instead show lower power and current consumption of Meetecho mobile (1.94 W and 523.88 mA, respectively) with respect to Fring (2.1 W and 577.78 mA, respectively). Finally, Fig. 4d depicts the downlink network traffic, which was on average 23 kbytes/s for Meetecho and 33 kbytes/s for Fring. Since Fring and Meetecho employ the same audio codec (i.e., G.711), these figures witness how the proprietary video codec adopted by Fring is more bandwidth-intensive than H.263. We do not report the uplink traffic because, as already explained, our client currently does not support video transmission.
IEEE Communications Magazine • August 2011
ROMANO LAYOUT
7/21/11
12:26 PM
Page 41
2000
120 CPU LOAD (%) meetecho CPU LOAD (%) skype
100
1800 1600 1400
80
1200 1000
60
800 40
600 400
20
200
Power (W) meetecho Power (W) skype
0
0 (a)
(b) 25,000
2000
Downlink (bytes/s) meetecho Downlink (bytes/s) skype
1800 20,000
1600 1400
15,000
1200 1000
10,000
800 600
5000
400 200
Power (W) meetecho Power (W) skype
0
0 (d)
(c) 25,000 Downlink (bytes/s) meetecho Downlink (bytes/s) skype 20,000
15,000
10,000
5000
0 (e)
Figure 3. Meetecho mobile (blue) vs. Skype (red): a) CPU level; b) power consumption; c) current consumption; d) downlink bandwidth; e) uplink bandwidth.
frames without overloading the CPU of the device.
QUALITY OF EXPERIENCE We conclude this section by providing the reader with figures useful for assessing the quality perceived by the other participants when a mobile user is involved. We focus on jitter, which is known as the key performance indicator of realtime communication channels. Figure 5a depicts evolution in time of the jitter for the audio RTP channel from the Symbian mobile client toward the Meetecho conferencing server, while Fig. 5b shows how the same parameter evolves when the Android mobile client is employed. In the latter case, a mean value of the jitter around 11 ms and peak values below 17 ms clearly indicate very good quality of the call. In the
IEEE Communications Magazine • August 2011
former case, instead, we found out that the mean value of the jitter was around 30 ms, while the peaks did not exceed 41 ms. These values still indicate good quality of the communication, also showing how the clustering technique we adopted for the audio stream (which we described earlier) did not affect the perceived quality of the call. The reported figures have been obtained by making use of either the WiFi or HSDPA connection available on the phone, obtaining very similar results.
LESSONS LEARNED The work we have presented taught us several lessons. First, we learned how conformance to standards, besides enabling interoperability, can definitely ease the development phase, as a
41
ROMANO LAYOUT
7/21/11
12:26 PM
Page 42
120 2500 100 2000 80 1500 60 1000
40
500
20
Power (W) meetecho Power (W) fring
CPU load (%) meetecho CPU load (%) fring 0
0 (a) 700
(b) 60,000
600
50,000
Downlink (bytes/s) meetecho Downlink (bytes/s) fring
500 40,000 400 30,000 300 20,000
200 100
Current (mA) meetecho Current (mA) fring
0
10,000 0
(c)
(d)
Figure 4. Meetecho mobile (blue) vs. Fring (red): a) CPU level; b) power consumption; c) current consumption; d) downlink bandwidth.
number of already existing libraries can be exploited. We showed how XMPP support can be added to Symbian systems by porting the Iksemel library to the S60 environment and to Android-based devices through the asmack library. As for SIP/SDP, as well as RTP, it is usually possible to exploit native APIs available on Symbian-based phones, while the open source project Sipdroid provides developers with implementations of such protocols suitable for the Android platform. We also learned that dealing with audio and video encoding/decoding is the trickiest. It is usually possible to leverage APIs made available by the SDK to handle audio, even though clustering audio samples is often necessary to achieve a good perceived quality. Exploiting hardware decoders of video frames, when available, proved to be the wrong choice as they performed very badly on both Symbian and Android. In order to concurrently access the audio resource (in both input and output), the device has to support full-duplex transmissions. While modern devices usually support full-duplex, this is often not the case of emulators provided by SDKs: hence, a further lesson is that just testing an application in an emulated environment might give the wrong perception of implementation mistakes. Finally, the performance figures derived and presented earlier show how video streaming functionality overloads the CPU of the device. Such figures, in the case of Meetecho, do not
42
depend on the actual number of participants involved in the communication, since the conferencing server with which our mobile client interacts takes care of audio and video mixing operations. This entails that, even when multiple participants are involved in a videoconference, a single flow containing a mosaic of the available contributions is sent to the client. Hence, the last lesson learned is that relying on server-side mixing, in the case of communications involving multiple participants, is strongly recommended when there are mobile clients involved.
CONCLUSIONS AND FUTURE WORK In this article we describe the design and implementation of a mobile client enabling users to participate in multimedia conferences involving both audio and video. The client supports most of the standard protocols used for media-rich real-time communications over the Internet and enables mobile users to access the Meetecho conferencing framework, an advanced playground for researchers wishing to evaluate (and troubleshoot) the protocols currently under standardization within the Real-Time Applications and Infrastructure area of the IETF. Meetecho mobile currently allows users to participate in a conference involving both fullduplex audio flows and simplex (i.e., receptiononly) video flows, with very good perceived quality, by effectively exploiting the available device resources.
IEEE Communications Magazine • August 2011
ROMANO LAYOUT
7/21/11
12:26 PM
Page 43
Jitter (ms) 45
Jitter (ms)
40
18
35
16
30
14 12
25
10 20 8 15
6
10
4
5
2 0
0
(b)
(a)
Figure 5. Time evolution of the jitter with a) Symbian; b) Android.
Work still has to be done before considering this effort complete. First, we have to enable video transmission from the device. The challenge resides in the capability to effectively capture video from the embedded device camera. Once done with this, in fact, the remaining functions are just associated with RTP-enabled transmission of the captured video frames (an issue we have already solved in the case of audio). Furthermore, support for new media can be added to the client. Work is already in full swing to let our client also support presentation sharing. This basically requires the capability to: • Upload a presentation file to the conference server • Receive from the server (and display on the screen) a sequence of presentation images • Send to the server triggers for commanding the presentation We also plan to enable passive reception, on the mobile client, of images representing snapshots of a collaborative whiteboard used by other (feature-rich) clients during a conference. In such a way, a mobile user, although not capable of modifying the whiteboard, can nonetheless keep track of what other users are drawing on it. As a last direction of future work, we have already started investigating the Apple iOS and RIM BlackBerry operating systems. We plan to make Meetecho Mobile available on those platforms in the near future.
REFERENCES [1] J. Rosenberg, “A Framework for Conferencing with the Session Initiation Protocol (SIP),” RFC 4353, Feb. 2006. [2] M. Barnes, C. Boulton, and O. Levin, “A Framework for Centralized Conferencing,” RFC 5239, June 2008. [3] G. Camarillo, J. Ott, and K. Drage, “The Binary Floor Control Protocol (BFCP),” RFC 4582, Nov. 2006. [4] M. Barnes et al., “Centralized Conferencing Manipulation Protocol,” draft-ietf-xcon-ccmp-12, Feb. 2011, work in progress. [5] A. Buono et al., “A Distributed IMS Enabled Conferencing Architecture on Top of a Standard Centralized Con-
IEEE Communications Magazine • August 2011
ferencing Framework,” IEEE Commun. Mag., vol. 45, no. 3, Mar. 2007. [6] A. Amirante et al., “Centralized Conferencing in the IP Multimedia Subsystem: From Theory to Practice,” J. Commun. Software and Sys., Mar. 2008. [7] P. Saint-Andre, “Extensible Messaging and Presence Protocol (XMPP): Core,” RFC 3920, Oct. 2004. [8] J. Rosenberg, “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” RFC 5245, Apr. 2010.
BIOGRAPHIES ALESSANDRO AMIRANTE (
[email protected])received both his M.Sc. degree in telecommunications engineering in 2007 and his Ph.D. degree in computer engineering and systems in 2010 from the University of Napoli Federico II. He is currently CTO at Meetecho s.r.l. and a senior researcher in the Computer Science Department of the same university His research interests fall in the field of networking, with special regard to next-generation network architectures and multimedia services over the Internet. TOBIA CASTALDI (
[email protected]) received his degree in telecommunications engineering from the University of Napoli Federico II in 2006. He is currently CEO at Meetecho s.r.l. and a senior researcher in the Computer Science Department of the same university. The main topic of his research concerns real-time applications for the next-generation Internet with special regard to the IP Multimedia Subsystem (IMS) architecture and services. L ORENZO M INIERO (
[email protected]) received his degree in computer engineering from the University of Napoli Federico II in 2006. He is currently COB at Meetecho s.r.l. and a senior researcher in the Computer Science Department of the same university. His research interests mostly focus on next-generation networks, network realtime applications, and communication protocols, with special emphasis on the related standardization efforts. SIMON PIETRO ROMANO (
[email protected]) is an assistant professor at the University of Napoli Federico II. His research interests fall in the field of networking, with special regard to real-time multimedia applications, network security, and autonomic network management. He is involved in a number of European research projects dealing with Critical Infrastructure Protection. He actively participates in IETF standardization activities, where he chairs the SPLICES working group on loosely coupled SIP devices.
43
