Hello!
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
internally.
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
http://www.sip-communicator.org/index.php/GSOC2008/FmjMedia. One
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.
Greetings,
Marek Zawirski
> 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
> transport.
> 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.
>
> Regards,
> Roland.
>
>
> 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
> as
> a SOC project]
>
> Marek Zawirski wrote:
>>> 1) Mylyn integration
>>> I'm asking really nicely Remy, is it possible at all? :) If not
> I'm
>>> 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
> bug
>>> reporter, possibly software client, or commenting developer. This
> is
>>> probably one of most obvious feature, but result in problem of
>>> mapping Issue-Tracking System (let me name it ITS if you don't
> mind)
>>> 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,
> possibly
>>> locally or on ITS. However, I don't now is ITS a good place for
> such
>>> 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
> know
>>> 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
> chat/conference
>>> 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
> issue
>>> 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
> chat
>>> 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
> recommendations
>>> 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
> IMHO
>>> it would be better to store them in ITS-usernames form in context
>>> (more general form), and define mappings in other part (as users
> may
>>> 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
> users.
>>>
>>> c) When having some task-oriented chat with somebody, it mabye
> useful
>>> 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
> developer.
>>> 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
>>> possibly.
>>>
>>> d) Some fun and maybe not possible;) Real-time task
> synchronization.
>>> When >= 2 developers work on some task(s) simultaneously and want
>>> online synchronization of their contexts without manual sync. I
> don't
>>> know Mylyn details yet, especially context model and
> synchronization
>>> model. So I'm not sure is it possible to create such
> synchronization
>>> 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
> everything
>>> 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
> Mylyn
> 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
> my
>> guess.
>>
>>
>> 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'.
> We
>>> 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
> application
>>>> sharing with VNC as one of implementation, or some existing
> interfaces
>>>> may be used (e.g. ISharedObject?). This could be used for session
>>>> sharing possibly. VNC protocol need to be implemented or some
> external
>>>> 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
> localhost,
>>> 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
> server.
>> Is it really needed? Do you mean better control or some tunneling
>> (with encryption?).
>
> Compression, encryption, and/or tunneling certainly can/could be
> done.
> Also, using ECF can distribute the VNC server output to several/group
> of
> receivers.
>
>> In simple model VNC server could just listen/bind on * interface,
> not
>> only localhost, being more standalone. All what is shared then is
> some
>> 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
> (on
> 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
> respond
> to certain kinds of mouse/keyboard input...for example.
>
>>
>>> Some months ago I tried to contact the VNClipse folks to ask them
> if
>>> they would be interested in working together...and didn't hear
>>> anything back. They may have been busy, or things may have
> changed,
>>> 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
> at
>>> dev.eclipse.org), and those *not* under EPL (the 'ECF Extras'
> hosted
>>> at ecf1.osuosl.org), so we can work around these issues for a SOC
>>> project in any case.
>> Did you mean TightVNC GPL implementation?
>
> Yes.
>
>
>> I've done some zoom in at its vncviewer code - VNC client. It
> appears
>> to be not very very complicated, ~20classes / ~20KLOC. However,
>> implementation is sticked to AWT/SWING, so would require embedding
> AWT
>> 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
> client.
>
> Yes.
>
>>> 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
> to
>>> them via a localhost socket connection as you suggest below (booo)
>>> :). There may very well be ways to write a VNC server in java
> using
>>> SWT...and given SWT's native implementation it could be
> sufficiently
>>> performant on some/all platforms. I don't know.
>>> But there are several people on the ECF committer list that are
> very
>>> good WRT SWT and UI: Boris Bokowski, Remy Suen, Chris Anisczyck
> and
>>> 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
> user-provided
>> 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,
> even
>> 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
> pose
> these questions in the SWT newsgroup(s)?
>
>> Still, some external native code could be started like with Skype,
> but
>> AFAIK VNC servers are provided in different ways and under
> different
>> 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
> name).
>
>> 3) SIP
>>
>>>> 4) SIP implementation, not yet made for ECF(?). I don't have much
>>>> experience (except user-side) with that protocol, just wondering
> how
>>>> 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
> SDP,
>> made as part of Java Specification Request. However, I've read it
> is
>> 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
>> implementations.
>> 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
> to
> do this, as I expect that's what the JAIN sip implementation does.
> I've
> 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
> know
> about.
>
>
>> 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
> audio,
>> compression and streaming code may be shared?
>
> That is very possible. I'll let Moritz and Roland answer your
> questions
> more directly.
>
> Thanks,
>
> Scott
>
> Ihr Postfach Logout
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-dev
--
Marek Zawirski [zawir]
marek.zawirski@xxxxxxxxx
