[sip-comm-dev] IcedJava: STUN/TURN and ICE


#1

Emil Ivov wrote:

Charles Chappell wrote:

  Just to net the list know, I've been working on an implementation of
STUN/ICE these past couple of weeks that implement RFC 5389 and MMUSIC-
ICE. Support for STUN/Datagram demultiplexing is built in, and an
RTPConnector for JMF/FMJ is in the works, though it's a separate
module to avoid unnecessary dependancies.

  I don't yet have a public version of this project ready, and it will
go through several more cycles before it's completed, but this is a
full time development project on my end, for a project at $DAYJOB, and
this particular module will be open-sourced when all is said and done.

Any idea of an approximate deadline?

  Functional for our purposes will be next week. I suspect functional for everyone else will take some doing, as I've done some thread and callback gymnastics so that the STUN listeners get data immediately, and suspect many projects will want access to a DatagramSocket or DatagramSocket like interface.

  It doesn't have roots in the STUN4J or JSTUN code bases

Ah that's a shame. It would certainly have been easier to collaborate if
it did.

  I've put some thought into how to make this project at least interface compatible with these earlier works, but on some levels, RFC 5389 completely scraps functionality that was present in 3489, making this somewhat awkward. I'm not that focused on backwards compatibility, so much as simply being able to coax a useful reply out of a 3489 server. (Which I can do at this point) Nothing in my code will create a useful reply to a 3489 client however, as they have an assumption of multiple IPs and multiple ports that I purposely ignore. (IcedJava tends to focus more on P2P use rather than client-server usage, though there is a limited server module)

though will
likely be licensed similarly as LGPL.

  I know that ICE is on the roadmap for SIP Communicator, and work has
started on other library adaptations, but, frankly, I didn't want to
wade through the largely obsoleted code bases of existing projects to
get this one to work. In that, I apologize for creating 'yet another'
STUN library, however, given that this is full time work for me, it
might be quicker to work with me on this project rather than working
part time on adapting one of the other STUN libraries into a full ICE
implementation.

I understand. A couple of more questions:

Where are you planning on hosting it?

  Java.net seems as good a place as any to me personally.

Would you be willing to accept developers from this project as
committers of the ICE stack?

This would invariably imply losing some of the copyright/IP so would it
also be acceptable to you employer?

  I'm weary of the ramifications of this. I need to look more into the legal ramifications, but if people are ok with being contributors, not owners, (and being noted as such in the license agreement) I'd be more happy with that classification, as it keeps IP issues to a minimum.

···

Cheers,
Emil