[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Google Summer Of Code ideas
|
Hi again,
I've learned some new things with new day, that I'd like to discuss
with somebody from your team before writing GSoC application. I've
finally decided to do a SIP/VoIP implementation and I've focused on
this task since yesterday.
I don't know however should I discuss it again on ecf-dev list or
should I contact with possible (proposed by you) mentor? I'd
appreciate some jabber or irc contact.
Greetings,
Marek Zawirski
On Wed, Mar 26, 2008 at 8:45 PM, Marek Zawirski
<marek.zawirski@xxxxxxxxx> wrote:
> 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
>
--
Marek Zawirski / zawir
marek.zawirski@xxxxxxxxx
