Nice to get some reply, Roland.
Yes, I'm considering SIP implementation seriously, that's interesting
one. So I think that I'll focus on this project :) Could you be a mentor
for such SIP/VoIP project, Roland? I don't actually know how process of
becoming mentor of GSoC at Eclipse looks like.
Again, did some research after your answer. I've found that JAIN-SIP
(JSIP reference implementation) seems to be a working implementation,
still popular and used. JSDP (SDP library) FAQ states that SDP part of
JAIN-SIP is somehow outdated. I'm hoping (and investigating) that it is
possible to send JSDP-generated SDP messages with JAIN-SIP. If so, it
maybe enough stuff to do signaling part.
Coming back to real challenge part as you say... RTP/Media. I thought
that Openfire is server doing something else. But ok, if you say it
includes such implementation I will try to look at it. I'm just
downloading source code and will search for. There is also Spark IM
client from Jive that has some SIP plugin. I wonder what does it use
Moritz, I've looked at your developer's log:
http://wiki.eclipse.org/VoIP_in_ECF%2C_GSoC07_DevLog. It seems that you
have used Smack API from Jive for XMMP/Jingle. Have you also used it for
voice compression, coding, transport (with JMF plugged into Smack API),
or am I wrong? I'll also download the code and look into.
As JMF looks to be orphaned by Sun, I've found some interesting
replacement-project: http://fmj-sf.net/. Some important VoIP audio
codecs are alredy supported
[http://fmj-sf.net/fmj/supported_formats.php], there is some RTP
implementation allowing sound stream to be plugged-in into RTP driver.
What is important, project is active, so there is a hope for future. It
is LGPL licensed. However, I'm not sure about RTP quality/status, as it
seems to be one of a GSoC task for this project
approach may be to use JMF and possibly later switch to FMJ as they use
the same or similar API.
The problem is that these protocols/codecs implementations are all from
different projects and there is no all-in-one library for doing all
tasks. This can make the project somewhat harder.
In a meanwhile I'll try to look closer at mentioned projects/libraries.
> Hello Marek,
> Your assumptions as far as the SIP implementation you mention is
> concerned are correct. Implementing the SIP signaling should be
> straight-forward but the real challenges lie with the RTP/Media
> There were quite some challenges with the JMF approach we evaluated
> with regards to portability and CODEC avialability... the JMF project
> has been relatively dormant for quite a while and my guess is it will
> not pick up momentum any time soon.
> The guys at Jive provided a custom RTP/Media implementation with the
> Openfire version 3.xx relase and we haven't yet been able to look at
> the details of that implementation. It may/should be possible
> to use their implementation (both from a licensing and code
> standpoint) in conjunction with a suitable signaling implementation
> to implement the ECF Telephony API (as a SIP provider plugin).
> AFAIK, Moritz already used/tried out early versions of the Openfire
> implementation within his ECF Telephony API jingle (signaling)
> provider so maybe he could shed more light on that.
> I am currently responsible for the IAX provider but currently taking
> a different approach which involves wrapping native libraries that
> provide both signaling and rtp media (a viable approach in the
> absence of suitable java implementations).
> The VOIP functionality within ECF is much demanded by the community
> and I personally think it will be great to have a SOC project take on
> the SIP implementation. We could certainly share more details if you
> are seriously cosidering such an implementation.
> Re: [ecf-dev] Google Summer Of Code ideas « »
> Von Scott Lewis <slewis@xxxxxxxxxxxxx> (» Adressbuch)
> An "Eclipse Communication Framework (ECF) developer mailing list."
> <ecf-dev@xxxxxxxxxxx>, Moritz Post <moritzpost@xxxxxx>,
> roland@xxxxxxxxxxxxxx, mik@xxxxxxxxxxx
> Datum Tue, 25 Mar 2008 15:02:32
> Hi Marek,
> [Moritz and Roland...please see below for questions about
> SIP/codecs/Java media]
> [Mik please see below for questions about Mylyn integration with ECF
> a SOC project]
> Marek Zawirski wrote:
>>> 1) Mylyn integration
>>> I'm asking really nicely Remy, is it possible at all? :) If not
>>> just leaving you list of some ideas (possibly stupid as I'm not
>>> experienced user of Mylyn).
>>> Major function implemented by Remy is sending tasks between users.
>>> I've thought what could be added and my output is:
>>> a) Chat/call with some user from issue-tracking system, such as
>>> reporter, possibly software client, or commenting developer. This
>>> probably one of most obvious feature, but result in problem of
>>> mapping Issue-Tracking System (let me name it ITS if you don't
>>> users database to IM users list. First, I thought about heuristic
>>> basing on usernames: cliking on username results in Menu "Chat
>>> with..." and possible guesses in your buddy list, or manual user
>>> selection. Such selection could be stored in some mapping,
>>> locally or on ITS. However, I don't now is ITS a good place for
>>> sensitive data?
>>> When looking for solution, I've found
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=152415 which address
>>> this problem and is related to Higgins framework(?). Do somebody
>>> what's the current status of these issue? I guess it would require
>>> changes in Mylyn itself possibly?
>>> Some generalization of a) would be creating mutliuser
>>> for a task. Similar problems I guess + additional issue: multiuser
>>> chat support in ECF providers.
>>> b) Also related to a). Make contacts/communication part of an
>>> context. ITS allows to define contacts of a task by providing:
>>> reporter, assigned user (or users, depending on ITS), commenting
>>> users. Is it enough?
>>> This would require Monitoring API implementation or some manual
>>> adding to context(?). As it may be hard to distinct whether such
>>> is related to this issue or is it "just" chat with friends during
>>> work, coding same time ;)
>>> However, when somebody is initiating shared editor session, it's
>>> quite sure that this contact is related to this task.
>>> Some contacts may be also extracted from @author tags of javadocs
>>> possibly. That's however, more language and company
>>> specific, I'm afraid. It's just another way of creating
>>> communication-context which might be seen as general problem.
>>> Anyway, there are still some problems with contacts mapping, as
>>> it would be better to store them in ITS-usernames form in context
>>> (more general form), and define mappings in other part (as users
>>> use different IM for example).
>>> Another problem is that creating communication/contacts context in
>>> form of Mylyn context will make it unusable for non-Mylyn ITS
>>> c) When having some task-oriented chat with somebody, it mabye
>>> to add log from part of conversation to ITS, don't you think? This
>>> may include extended problem recognition after interview with
>>> reporter or implementation status details after chat with
>>> However, it would be nice to do it easily, without too much manual
>>> reformatting, so just selecting some fragment. That's mainly
>>> copy-paste transformation support possibly. That's small feature
>>> d) Some fun and maybe not possible;) Real-time task
>>> When >= 2 developers work on some task(s) simultaneously and want
>>> online synchronization of their contexts without manual sync. I
>>> know Mylyn details yet, especially context model and
>>> model. So I'm not sure is it possible to create such
>>> session. This may be a complex one.
>>> I also wonder how much part of implementation of a) - d) or others
>>> require intervention in Mylyn code. Is it in fact ECF project, or
>>> Mylyn project using ECF (is it a problem?)? Possibly not
>>> could be done as Mylyn Bridge as my first my guess.
>> I also wonder how much part of implementation of a) - d) or others
>> require intervention in Mylyn code. Is it in fact ECF project, or
>> Mylyn project using ECF (is it a problem?)?
> It's not inherently a problem, but would require coordination with
> team (if it in fact does require changes to Mylyn code as opposed to
> additions via further plugins). I've copied Mik Kersten on this email
> to get his input on some of the questions you raise.
>> Possibly not everything could be done as Mylyn Bridge as my first
>> 2) VNC
>>> Yes...this would be a terrific project IMHO. The reason we haven't
>>> worked on this so far is captured in a single word: 'resources'.
>>> just haven't had enough time/interested people to do it.
>> (possibly) resourcesNumber++ ;>
> Sounds great.
>>>> What about realization?
>>>> I've read about proposed idea to create some interface for
>>>> sharing with VNC as one of implementation, or some existing
>>>> may be used (e.g. ISharedObject?). This could be used for session
>>>> sharing possibly. VNC protocol need to be implemented or some
>>>> library used.
>>> Yes. There are different approaches here...one would be to make a
>>> localhost socket connection to a running VNC server/host, and
>>> basically have the ECF host get screen sharing data from
>>> send it over the wire, and then display on remote clients.
>> I wonder what is a purpose of making ECF a proxy for real VNC
>> Is it really needed? Do you mean better control or some tunneling
>> (with encryption?).
> Compression, encryption, and/or tunneling certainly can/could be
> Also, using ECF can distribute the VNC server output to several/group
>> In simple model VNC server could just listen/bind on * interface,
>> only localhost, being more standalone. All what is shared then is
>> URL and possibly some settings? This may have some drawbacks
> maybe... (?)
> This would be OK, but it would limit what you can/could do with ECF
> servers or clients). For example...if you are sending the VNC server
> screen output and mouse/keyboard input over ECF provider, then you
> can/could have some ways to do a) recording; b) have bots that
> to certain kinds of mouse/keyboard input...for example.
>>> Some months ago I tried to contact the VNClipse folks to ask them
>>> they would be interested in working together...and didn't hear
>>> anything back. They may have been busy, or things may have
>>> so it would probably be worthwhile to try to contact them again. I
>>> can't immediately remember what the license was, but at that time
>>> they were not making the source available.
>> I'll just write to them.
> OK, great.
>>> One other licensing issue is that the VNC source itself (including
>>> the java clients) are GPL, so if we want to use/modify any of that
>>> code the resulting code cannot be under the EPL (Eclipse license).
>>> ECF has both EPL-based components (i.e. those hosted/distributed
>>> dev.eclipse.org), and those *not* under EPL (the 'ECF Extras'
>>> at ecf1.osuosl.org), so we can work around these issues for a SOC
>>> project in any case.
>> Did you mean TightVNC GPL implementation?
>> I've done some zoom in at its vncviewer code - VNC client. It
>> to be not very very complicated, ~20classes / ~20KLOC. However,
>> implementation is sticked to AWT/SWING, so would require embedding
>> Canvas component or forking project and porting it to SWT. In the
>> latter case, things looks rather straight-forward.
>> BTW: interesting TightVNC feature is recording of session from
>>> I personally do not, as I'm not an SWT expert. In other java-based
>>> impls of VNC, we've used the native code impls of VNC and talked
>>> them via a localhost socket connection as you suggest below (booo)
>>> :). There may very well be ways to write a VNC server in java
>>> SWT...and given SWT's native implementation it could be
>>> performant on some/all platforms. I don't know.
>>> But there are several people on the ECF committer list that are
>>> good WRT SWT and UI: Boris Bokowski, Remy Suen, Chris Anisczyck
>>> others. Hopefully we can pull them into the conversation
>> I'd appreciate your comments:) Things that I'm especially wondering
>> are they possible:
>> - is it possible to make SWT "secondary" output to some
>> framebuffer class, register some redrawing listener for a whole
>> desktop, even when non-SWT window is focused?
>> - is it possible to grab mouse/keyboard input from other windows,
>> when non-SWT window is focused?
> I doubt it (for both questions), but this is indeed something that
> should be asked of SWT experts. Perhaps it would be a good idea to
> these questions in the SWT newsgroup(s)?
>> Still, some external native code could be started like with Skype,
>> AFAIK VNC servers are provided in different ways and under
>> licenses. Eventually it could be configured by user, but what are
>> Eclipse-embedding benefits then...
>> BTW What java-based impl did you mean, Scott? Some closed-source?
> No, I meant the java client provided with realvnc (I think that's the
>> 3) SIP
>>>> 4) SIP implementation, not yet made for ECF(?). I don't have much
>>>> experience (except user-side) with that protocol, just wondering
>>>> laborious this task may be...
>>> This is a great question for our two VOIP committers: Moritz Post
>>> (did the Jingle VOIP SOC project last year), and Roland Fru (has
>>> worked quite a lot with SIP and Asterisk).
>>> In either case I think a SIP provider (implementer of the ECF call
>>> API) would be great.
>> Ok, again, I'm asking kindly for some comments:)
>> I've found JAIN SIP API and reference implementation of SIP and
>> made as part of Java Specification Request. However, I've read it
>> bit outdated, on JSDP page - don't know how/why. JSDP is unofficial
>> (out of JSR) implementation od SDP. Basic signaling part of this
>> project may be not very hard. I'm expecting more problems with
>> interoperability and mainly - transport/RTP and codecs/audio
>> Or do you have other experiences?
> I'm forwarding this onto Moritz Post, who did the 2007 VOIP project
> (Jingle). He ended up using Java Media codecs/audio implementations
> do this, as I expect that's what the JAIN sip implementation does.
> noticed that the JAIN SIP implementation doesn't seem to be getting a
> lot of new work recently, so I'm not sure of it's status. Moritz and
> Roland please comment about existing SIP implementations that you
>> The codecs, audio, RTP part may be already implemented as part of
>> Moritz Post GSoC work possibly(?). AFAIK jingle is just another
>> signaling protocol with similar role as SIP with SDP, so maybe
>> compression and streaming code may be shared?
> That is very possible. I'll let Moritz and Roland answer your
> more directly.
> Ihr Postfach Logout
> ecf-dev mailing list
Marek Zawirski [zawir]