meetecho mobile: accessing an ietf-compliant conferencing framework from cellular devices

CONTEXT AND MOTIVATION

Multimedia conferencing has lately attractedinterest from the international research commu-nity, due to the many challenges it entails inboth the control and data planes.

Within the Internet Engineering Task Force(IETF), work on conferencing was originally car-ried out within the SIPPING Working Group(WG) [1], whose purpose was to document howSession Initiation Protocol (SIP) could be usedto implement rich multimedia applications.

Afterward, the XCON [2] working group waschartered in order to define protocols, datamodels, and interfaces for the management ofcentralized conferences. XCON’s main mile-stones have been met ([2–4]), and the remainingwork is on the right track toward successful com-pletion. Meanwhile, a proposal to extend XCONtoward a distributed scenario [5] has been for-mulated by the authors of this article.

Indeed, we are active contributors in all ofthe above cited groups and have since longworked on pioneering implementations of theproposed standards, which have proven helpfulin the definition, evaluation, and refinement ofthe involved protocols, as well as in the descrip-tion of so-called best common practices (BCPs)associated with their utilization.

The main outcome of the mentioned effortshas been the creation of an innovative real-timecollaboration framework called Meetecho [6],which involves most of the newly defined mecha-nisms and protocols, thus also acting as a play-ground for the assessment of the proposedfunctionality, as well as for its potential refine-ment.

Meetecho currently supports the followingfunctions:• Extensible Messaging and Presence Proto-

col (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 ManipulationProtocol (CCMP) [4]Lately, a consistent part of our efforts has

been devoted to enabling access to the Meete-cho platform from cellular devices. Hence, here-in we present Meetecho Mobile, a conferencingclient designed for mobile devices.

Although not supporting all of the functionsmentioned for the fully-fledged client running ondesktop computers, Meetecho Mobile allowsmobile users to participate in multimedia confer-ences involving, besides an XMPP-based chat,both audio and video streams. It currently sup-ports full-duplex audio streaming, together withpassive reception of the mixed video stream (nosupport is currently available for real-time cap-ture and transmission of video generated at themobile device itself). Support for moderationhas been introduced as well, while there is nosupport for CCMP as of yet.

The remainder of the article is organized asfollows. We present some related work. We dis-cuss the main requirements that have to be guar-anteed by any mobile conferencing client wishingto access a Meetecho-enabled conference. Wethen move to the design of the mobile client,whose implementation is detailed, which focuseson the most challenging issues we faced in order

IEEE Communications Magazine • August 201136 0163-6804/11/$25.00 © 2011 IEEE

ABSTRACT

In this article we present Meetecho Mobile,an innovative conferencing client designed formobile devices. Such a client provides access toconferences compliant with the most recent stan-dard proposals currently under definition withinthe IETF. It allows mobile users to participate inmultimedia conferences involving, besides anXMPP-based chat, both audio and video streams.The article discusses the design and implementa-tion of the conferencing client and highlights themost notable solutions we devised in order toeffectively handle a whole suite of protocols,ranging from signaling (SIP/SDP, XMPP) toreal-time streaming (RTP). We also provideinformation about the main performance figurescharacterizing the client’s behavior.

TOPICS IN DESIGN AND IMPLEMENTATION

Alessandro Amirante, Tobia Castaldi, and Lorenzo Miniero, Meetecho

Simon Pietro Romano, University of Napoli Federico II

Meetecho Mobile: Accessing an IETF-Compliant ConferencingFramework from Cellular Devices

ROMANO LAYOUT 7/21/11 12:26 PM Page 36

IEEE Communications Magazine • August 2011 37

to enable support for a wide suite of protocols,ranging from signaling (SIP/SDP, XMPP) toreal-time streaming (RTP). We provide informa-tion about the main performance figures charac-terizing the client’s behavior. Finally, weconclude the article by summarizing the mainachievements while also presenting directions ofour future work.

RELATED WORKAs multimedia communications over the Internethave become very popular, a number of solutionshave been developed to access such functionalityfrom mobile devices. Here we focus on the solu-tions suitable for devices equipped with eitherthe Symbian or Android OS, since they representthe two reference platforms we present in theimplementation section of the article.

A mobile version of the Skype software isavailable, allowing Skype users to place VoIPcalls, chat, and share files. As to the VoIP func-tionality, it allows audio flows to be transmitted,and support for video was introduced in early2011. Audio streams are carried through a pro-prietary protocol and encoded in a proprietaryformat. Furthermore, there is no possibility toset up a conference call involving more than twoparticipants.

Fring is a mobile peer-to-peer Internet tele-phony network enabling users to talk and chatusing ICQ, Google Talk, Windows Live Messen-ger, AIM, Yahoo Messenger, and SIP providers.It supports two-way video calls (within the Fringnetwork), while multi-user conference calls arenot yet available. Fring used to offer support forSkype, too, but this feature was recently removeddue to the large load impact it was having onSkype servers.

Even if none of the software solutions pre-sented above is actually a conferencing client,they nonetheless represent useful terms of com-parison if one is interested in evaluating the per-formance related to VoIP functionality, as weshow later.

MEETECHO MOBILE:PROTOCOL REQUIREMENTS

To build a client capable to interact with a stan-dard XCON conferencing framework, a numberof requirements have to be taken into account.There are a number of protocols that have to benecessarily implemented on the client’s side.

First, since our solution uses instant messag-ing as an orchestrating technology, the client hasto provide support for XMPP [7]. This is justi-fied by the need to manage buddy lists, as wellas to enable instant messaging communication.XMPP can also be exploited as a basic confer-ence control protocol, allowing the client to:• Retrieve information about conferences and

conference participants• Start the process of joining a conferenceIn the control plane, support for SIP is alsorequired. SIP is in fact the most suitable choicewhen it comes to setting up multimedia sessionsamong the many clients involved in a confer-ence.

It is worth spending a few words on thedebate currently ongoing about SIP vs. XMPP.The former has been originally conceived forsession setup purposes, while the latter has beenthought for IM and presence. Nevertheless, thedevelopment of extensions to both protocolsmade their scopes overlap, so that SIP can beexploited for instant messaging, whereas XMPPis also suitable for call signaling. We decided toadopt both protocols for their native purposes,thus fostering interoperability with both legacySIP and XMPP clients.

Coming to the data plane, once a session hasbeen successfully established, the conferencingclient 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 transmissionAll of the mentioned requirements are effec-

tively supported in our mobile client, except forthe capability to send video through RTP. Thislast point represents one of the subjects of ourcurrent work and is further discussed in theremarks that conclude this article.

DESIGNAs anticipated before, the mobile client has tobe 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 moderationAlso, NAT-traversal issues should also be takeninto account.

Interactions among a mobile user, the Meete-cho client and the conference focus are illustrat-ed in the sequence diagram in Fig. 1.

Indeed, the architecture we devised is compli-ant with the three-tier approach, whereby anapplication is divided in three inter-operating lay-ers dedicated, respectively, to the graphical userinterface, to the business logic and to the man-agement of back-end data structures. Such layersinteract on the basis of a client-server paradigm(the GUI is a client of the business logic, which isin turn client of the data management layer). Thisis achieved through the definition of interfaces.

The business logic layer can be considered asthe main engine of the application and it can inturn be designed following different architecturalmodels. In this paragraph we deal with thedesign of the mobile conferencing client engine,1for which we adopted a two-tier model, compris-ing the following two levels (Fig. 2):• The first level provides all functional

requirements (login, participation in a con-ference, etc.). It is made of a single module,called DConengine, acting as an interfacetoward the application layer above.

• The second level looks after operationalrequirements and is divided into the follow-ing independent modules:–XMPP engine: a presence and chat module–SIP/SDP engine: a session setup and man-agement module

1 For the sake of brevity,we skip the details associ-ated with the design of thegraphical user interface,which, in the case ofhandheld devices, has itsown peculiarities andchallenges.

The architecture we

devised is compliant

with the three-tier

approach, whereby

an application is

divided into three

interoperating layers

dedicated, respec-

tively, to the graphi-

cal user interface,

the business logic,

and the manage-

ment of back-end

data structures. Such

layers interact on the

basis of a client-

server paradigm.


IEEE Communications Magazine • August 201138

–RTP engine: a real-time streaming module–Audio engine: dedicated to the manage-ment of audio streams–Video engine: dedicated to the manage-ment of video streams–BFCP engine: dedicated to moderationaspects–NAT engine: dedicated to NAT-traversalIntermodule communication can happen just

through vertical interactions, on the basis of thewell-known Observer/Observable design pattern.Such a pattern is often used when there is aneed to keep the state of a number of indepen-dent objects under control and can be fruitfullyemployed as an architectural basis for a genericevent management system.

IMPLEMENTATIONIn this section we present how we implementedthe designed conferencing client on both a Sym-bian OS architecture and on an Android system.

IMPLEMENTATION CHOICESSymbian — Among the numerous developmentplatforms available for the Symbian OS, wechose the S60 SDK, in one of its most recenteditions (the fifth). As to the programming lan-

guage, we had two main options available:• Java micro edition• C++ for SymbianWe made a thorough comparison between thetwo application programming interfaces (APIs)available and realized that the best option, inour case, was C++, since it covers almost 80percent of the functionality needed at the client(which is much more than the corresponding setof functions available in Java).

We realized the main client engine as adynamic link library (DLL), so as to provide ageneral-purpose conferencing module alsoexploitable by applications other than ourMeetecho mobile client.

Android — For what concerns Android, werelied on its official SDK and used Java, which isthe official programming language for Androiddevices.

To strike the balance between functionalityand interoperability, we developed our applica-tion for version 1.6 of the firmware, which,despite the increased functions of 2.1- and 2.2-based devices, is still one of the most deployedin the Android market. The Android imple-mentation was realized as a standalone applica-tion.

Figure 1. High-level sequence diagram illustrating interactions among a mobile user, Meetecho mobile andthe Meetecho conference focus.

1 : Login()2 : Notify presence via XMPP()

3 : Send buddy and conference list via XMPP()

5 : Join conference via SIP/SDP()

6 : RTP-based media streaming()

7 : RTP-based media streaming()

9 : Logout from conference via SIP()

11 : Cancel presence via XMPP()

4 : Select conference()

8 : Leave conference()

10 : Logout from system()

Meetecho mobile

: Mobile user

Meetecho focus

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

which avoids an

annoying screeching

effect due to trans-

mission delays.

ROMANO LAYOUT 7/21/11 12:26 PM 8


XMPP

Symbian — The S60 fifth edition frameworkdoes not natively provide an implementation ofXMPP . Nonetheless, it allows programmers toembed code written in C or C++. Hence, wechose to use the code developed within the opensource project named Iksemel, which makesavailable a porting for Symbian.

The mentioned Iksemel code has been portedto the Symbian S60 environment and made avail-able as a DLL, which has been used as a basisfor the development of the presence module ofthe mobile client.

Android — While the first versions of Androidprovided an XMPP stack, latest versions (includ-ing 1.6) removed such a native support for theprotocol. We hence looked for a viable solutionand found the asmack protocol stack, which isan open source Android port of the well knownSmack stack we had already used for our desk-top application.

We implemented XMPP as an Android ser-vice and configured all our Activities as listenersof XMPP events to let them become aware ofthe current state of the sessions.

SIP/SDPSymbian — The SIP module, including all partsassociated with SDP-based session negotiations,has been built on top of a rich API available forthe S60 framework and providing functionsneeded for registering clients, negotiating ses-sions through SDP, resolving URIs, sending highlevel messages destined to VoIP applications.

Android — For what concerns SIP/SDP, welooked for a valid Java implementation thatcould be somehow re-used in the Android SDK.Considering our desktop client application usesthe well-known MjSIP stack, we looked forAndroid ports of the library, and discovered theSipDroid project, which provides an open sourceSIP client for Android devices, and is actuallybased on a modified version of MjSIP. Weexploited such work in our client, by removingunneeded features, at the same time adding sup-port for re-INVITEs.

RTPSymbian — Like the SIP/SDP module, also theRTPEngine has been built on top of the baseclasses provided by the S60 framework, and pro-vides all functionality needed when dealing withRTP transmissions.

We remark that the RTPEngine we realizedhandles audio and video streams in differentways. In fact, we borrowed from Java MediaFramework a clustering technique for audiopackets that avoids an annoying screechingeffect due to transmission delays: we first bufferfour RTP packets and immediately thereaftersend them all together as a single burst. Eachpacket contains a 20 ms audio sample; hence,the first transmission happens with a delay of 80ms. From this instant on, we alternate bufferingperiods (during which the next four samples areaccumulated) with burst transmission periods.The two activities iterate with a period of about

80 ms. With this approach, we can emulate abehavior in which, on average, four 20-ms-longaudio samples are transmitted every 80 ms,which is exactly the expected behavior of a regu-lar audio source. By appropriately using thetimestamp field of the RTP header of the trans-mitted samples, we are able to reconstruct thecorrect time sequence at the receiver.

Android — On Android, RTP support has beendeployed 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 needany modification in order to work onAndroid.In both cases we also added a way to put a

call on hold and to dynamically limit RTP chan-nels to a single direction (e.g., for users onlyinterested in listening to a conference) in ordernot to waste bandwidth that might be paid for.

AUDIO ENCODING/DECODINGSymbian — The S60 SDK makes available theAudio Streaming API for audio management,which offers specific interfaces toward the low-level controller of the multimedia framework(MMF) for Symbian OS. Hence, we exploited itin a straightforward way to implement the Audio-Engine, by sending/receiving audio data to/fromthe MMF in an incremental fashion. In this case,the codec employed was G.711.

Android — As already anticipated, for audio werelied on the SipDroid library. We used theGSM audio codec, which gave us a good trade-off between voice quality and bandwidth con-sumption. Speakerphone support was also basedon SipDroid.

VIDEO ENCODING/DECODINGThe implementation of the video engine defi-nitely represents the most challenging task wehad to face and for which we still have someimportant open issues.

As already said, our work currently lacks thecapability of sending video. Hence, the issue ofhow to encode video frames is not addressed inthis article. On the other hand, video decodingcan be performed either by exploiting the hard-ware decoder available on the device, or throughsoftware. Although the former approach mightseem more attractive, we embraced the softwareapproach because a hardware decoder for thedesired format is not always available on thedevice.

Figure 2. Client’s engine architecture.

XMPPengine

DConEngine

SIP/SDPengine

RTPengine

Audioengine

Videoengine

BFCPengine

NATengine



In the following we describe how we imple-mented a video software decoder. We chose theH.263 codec as the Meetecho server providesusers with H.263-encoded video streams.

Symbian — The video engine implements afinite state machine cyclically evolving amongthree different states, loading, decoding, andbitmapping, the last two of which are executed inthreads that are separated from the rest of theapplication, since the processes of decoding andbitmap construction are both CPU-bound andtake resources away from the other applicationactivities. By using separated threads having lowexecution priority, we forced the application todedicate to them just the processor idle times.

Android — Video support on Android was alsochallenging. In fact, while the Android SDK pro-vides efficient APIs to access and process bothincoming and outgoing audio streams, this isonly partially true when it comes to video. TheSDK provides a native H.263 codec, but there isno way to exploit it with streams: the only way toaccess it is through the MediaPlayer API, whichonly 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 streamsourselves (through jrtp). As a final step, weimplemented a custom view for the presentationof the decoded frames.

MODERATIONSymbian — Rather than implementing theclient side of the Binary Floor Control Protocol(BFCP), we provided our framework with a serv-er-side dual tone multifrequency (DTMF) inter-face to the floor control server. We realizedbasic moderation functionality (i.e., floorrequest/release) through DTMF tones carriedwithin RTP packets.

Android — Besides the mentioned DTMF inter-face, on Android we also implemented the BFCPclient through the same Java library alreadyavailable for the Meetecho desktop client.

NAT-TRAVERSALSeveral NAT traversal techniques have been stan-dardized, the most effective one being the Interac-tive Connectivity Establishment (ICE) protocol[8]. ICE leverages the use of STUN and TURN inorder to circumvent NAT elements placed alongthe communication path. For our purposes,instead we chose to rely on a server-side approachto NAT traversal, exploiting an RTP proxy. This isreasonable in XCON since media packets alwaysflow through the conference focus; hence, RTPproxying will not introduce any further delay.

EXPERIMENTAL CAMPAIGNIn this section we present the results of the trialswe conducted to show how Meetecho mobilecompares to the clients introduced earlier.

USING A REAL SYMBIAN DEVICETo have an estimation of the performance of oursoftware on the real device, we used the Energy

Profiler, an application allowing power consump-tion and several other parameters to be trackedon S60 devices. With this application running inthe background, we placed a call with Skype(which, we recall, only supports audio calls), andevaluated resource consumption in terms ofCPU load, power, current, and bandwidth. Wecompared such parameters with the figuresresulting from Meetecho mobile while accessingan audio-only conference. Figure 3a shows howSkype took up, on average, around 43 percent ofthe CPU, while Meetecho mobile used around26 percent. Figures 3b and 3c show that powerand current consumptions were pretty much thesame, while Figs. 3d and 3e show that our band-width occupation levels were around 13 kbytes/s(downstream) and 10 kbytes/s (upstream),against the 5 kbytes/s (downstream) and 2.5kbytes/s (upstream) generated by Skype. Boththe CPU and bandwidth level results can beexplained by recalling that Meetecho mobileemploys the G.711 format for encoding theaudio flows, which is known to be bandwidthintensive while taking few CPU cycles for theencoding/decoding operations.

To assess the performance of our client whenvideo streams are involved, we repeated thesame experimental campaign comparing the fig-ures resulting from the Fring software whilemaking a video call, and Meetecho mobile whileparticipating in a videoconference. Figure 4ashows how, in both cases, adding video function-ality brought the CPU level of the real device toaround 100 percent. Figures 4b and 4c insteadshow lower power and current consumption ofMeetecho mobile (1.94 W and 523.88 mA,respectively) with respect to Fring (2.1 W and577.78 mA, respectively). Finally, Fig. 4d depictsthe downlink network traffic, which was on aver-age 23 kbytes/s for Meetecho and 33 kbytes/s forFring. Since Fring and Meetecho employ thesame audio codec (i.e., G.711), these figures wit-ness how the proprietary video codec adopted byFring is more bandwidth-intensive than H.263.We do not report the uplink traffic because, asalready explained, our client currently does notsupport video transmission.

USING A REAL ANDROID DEVICEWith 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 com-

munications, performed really badly on thereal device.

This last issue is already known to the Skypecommunity, as witnessed by several posts onSkype’s forum, and seems to depend on the spe-cific device we used. Hence, in this subsectionwe limit ourselves to providing the figures char-acterizing the behavior of Meetecho mobile.Bandwidth consumption was exactly the same aswith Symbian in both the audio-only and audio-video scenarios, which is straightforward sincewe adopted the same codecs. On the other hand,the mean CPU level was around 10 percentwhen only audio is involved, reaching 50 percentwhen video reception is involved, too. This lastresult shows how the software decoder we real-ized allows us to receive H.263-encoded video

Work still has to be

done before consid-

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.



frames without overloading the CPU of thedevice.

QUALITY OF EXPERIENCEWe conclude this section by providing the readerwith figures useful for assessing the quality per-ceived by the other participants when a mobileuser is involved. We focus on jitter, which isknown as the key performance indicator of real-time communication channels. Figure 5a depictsevolution in time of the jitter for the audio RTPchannel from the Symbian mobile client towardthe Meetecho conferencing server, while Fig. 5bshows how the same parameter evolves when theAndroid mobile client is employed.

In the latter case, a mean value of the jitteraround 11 ms and peak values below 17 ms clear-ly indicate very good quality of the call. In the

former case, instead, we found out that themean value of the jitter was around 30 ms, whilethe peaks did not exceed 41 ms. These valuesstill indicate good quality of the communication,also showing how the clustering technique weadopted for the audio stream (which wedescribed earlier) did not affect the perceivedquality of the call. The reported figures havebeen obtained by making use of either the WiFior HSDPA connection available on the phone,obtaining very similar results.

LESSONS LEARNEDThe work we have presented taught us severallessons. First, we learned how conformance tostandards, besides enabling interoperability, candefinitely ease the development phase, as a

Figure 3. Meetecho mobile (blue) vs. Skype (red): a) CPU level; b) power consumption; c) current consumption; d) downlink bandwidth;e) uplink bandwidth.

(a)

20

0

40

60

80

100

120

(b)

1000

0

800

600

400

200

1200

1400

1600

1800

2000

(c)

1000

0

800

600

400

200

1200

1400

1600

1800

2000

(d)

5000

0

10,000

15,000

20,000

25,000

(e)

5000

0

10,000

15,000

20,000

25,000

Downlink (bytes/s) meetechoDownlink (bytes/s) skype

Downlink (bytes/s) meetechoDownlink (bytes/s) skype

Power (W) meetechoPower (W) skype

Power (W) meetechoPower (W) skype

CPU LOAD (%) meetechoCPU LOAD (%) skype



number of already existing libraries can beexploited. We showed how XMPP support canbe added to Symbian systems by porting theIksemel library to the S60 environment and toAndroid-based devices through the asmacklibrary. As for SIP/SDP, as well as RTP, it isusually possible to exploit native APIs availableon Symbian-based phones, while the open sourceproject Sipdroid provides developers with imple-mentations of such protocols suitable for theAndroid platform.

We also learned that dealing with audio andvideo encoding/decoding is the trickiest. It is usu-ally possible to leverage APIs made available bythe SDK to handle audio, even though clusteringaudio samples is often necessary to achieve agood perceived quality. Exploiting hardwaredecoders of video frames, when available, provedto be the wrong choice as they performed verybadly on both Symbian and Android.

In order to concurrently access the audioresource (in both input and output), the devicehas to support full-duplex transmissions. Whilemodern devices usually support full-duplex, thisis often not the case of emulators provided bySDKs: hence, a further lesson is that just testingan application in an emulated environmentmight give the wrong perception of implementa-tion mistakes.

Finally, the performance figures derived andpresented earlier show how video streamingfunctionality overloads the CPU of the device.Such figures, in the case of Meetecho, do not

depend on the actual number of participantsinvolved in the communication, since the confer-encing server with which our mobile client inter-acts takes care of audio and video mixingoperations. This entails that, even when multipleparticipants are involved in a videoconference, asingle flow containing a mosaic of the availablecontributions is sent to the client. Hence, thelast lesson learned is that relying on server-sidemixing, in the case of communications involvingmultiple participants, is strongly recommendedwhen there are mobile clients involved.

CONCLUSIONS AND FUTURE WORKIn this article we describe the design and imple-mentation of a mobile client enabling users toparticipate in multimedia conferences involvingboth audio and video. The client supports mostof the standard protocols used for media-richreal-time communications over the Internet andenables mobile users to access the Meetechoconferencing framework, an advanced play-ground for researchers wishing to evaluate (andtroubleshoot) the protocols currently under stan-dardization within the Real-Time Applicationsand Infrastructure area of the IETF.

Meetecho mobile currently allows users toparticipate in a conference involving both full-duplex audio flows and simplex (i.e., reception-only) video flows, with very good perceivedquality, by effectively exploiting the availabledevice resources.

Figure 4. Meetecho mobile (blue) vs. Fring (red): a) CPU level; b) power consumption; c) current consumption; d) downlink bandwidth.

(a)

20

0

40

60

80

100

120

(b)

0

500

1000

1500

2000

2500

Power (W) meetechoPower (W) fring

CPU load (%) meetechoCPU load (%) fring

(c)

100

0

200

300

400

500

600

700

Current (mA) meetechoCurrent (mA) fring

(d)

10,000

0

20,000

30,000

40,000

50,000

60,000Downlink (bytes/s) meetechoDownlink (bytes/s) fring



Work still has to be done before consideringthis effort complete. First, we have to enablevideo transmission from the device. The chal-lenge resides in the capability to effectively cap-ture video from the embedded device camera.Once done with this, in fact, the remaining func-tions are just associated with RTP-enabled trans-mission of the captured video frames (an issuewe have already solved in the case of audio).

Furthermore, support for new media can beadded to the client. Work is already in full swingto let our client also support presentation shar-ing. 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 presentationWe also plan to enable passive reception, on

the mobile client, of images representing snap-shots of a collaborative whiteboard used byother (feature-rich) clients during a conference.In such a way, a mobile user, although not capa-ble of modifying the whiteboard, can nonethelesskeep track of what other users are drawing on it.

As a last direction of future work, we havealready started investigating the Apple iOS andRIM BlackBerry operating systems. We plan tomake Meetecho Mobile available on those plat-forms 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 Manipula-

tion Protocol,” draft-ietf-xcon-ccmp-12, Feb. 2011,work in progress.

[5] A. Buono et al., “A Distributed IMS Enabled Conferenc-ing Architecture on Top of a Standard Centralized Con-

ferencing Framework,” IEEE Commun. Mag., vol. 45,no. 3, Mar. 2007.

[6] A. Amirante et al., “Centralized Conferencing in the IPMultimedia Subsystem: From Theory to Practice,” J.Commun. Software and Sys., Mar. 2008.

[7] P. Saint-Andre, “Extensible Messaging and PresenceProtocol (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.

BIOGRAPHIESALESSANDRO AMIRANTE ([email protected])received bothhis M.Sc. degree in telecommunications engineering in2007 and his Ph.D. degree in computer engineering andsystems in 2010 from the University of Napoli Federico II.He is currently CTO at Meetecho s.r. l. and a seniorresearcher in the Computer Science Department of thesame university His research interests fall in the field ofnetworking, with special regard to next-generation net-work architectures and multimedia services over the Inter-net.

TOBIA CASTALDI ([email protected]) received his degreein telecommunications engineering from the University ofNapoli Federico II in 2006. He is currently CEO at Meetechos.r.l. and a senior researcher in the Computer ScienceDepartment of the same university. The main topic of hisresearch concerns real-time applications for the next-gener-ation Internet with special regard to the IP MultimediaSubsystem (IMS) architecture and services.

LORENZO MINIERO ([email protected]) received hisdegree in computer engineering from the University ofNapoli Federico II in 2006. He is currently COB at Meetechos.r.l. and a senior researcher in the Computer ScienceDepartment of the same university. His research interestsmostly focus on next-generation networks, network real-time applications, and communication protocols, with spe-cial emphasis on the related standardization efforts.

SIMON PIETRO ROMANO ([email protected]) is an assistantprofessor at the University of Napoli Federico II. Hisresearch interests fall in the field of networking, with spe-cial regard to real-time multimedia applications, networksecurity, and autonomic network management. He isinvolved in a number of European research projects dealingwith Critical Infrastructure Protection. He actively partici-pates in IETF standardization activities, where he chairs theSPLICES working group on loosely coupled SIP devices.

Figure 5. Time evolution of the jitter with a) Symbian; b) Android.

(a)

Jitter (ms)

5

0

10

15

20

25

30

35

40

45

(b)

Jitter (ms)

4

0

2

6

8

10

12

14

16

18


meetecho mobile: accessing an ietf-compliant conferencing framework from cellular devices

Documents