Vladimir Ralev wrote:
Hmm, yes. It seems we are not going to switch to LGPL soon, but this
shouldn't be a problem since GPL will allow you to either adopt it as a
3rd party dependency, like some of your existing GPL dependencies or if
you need more control over it (to fix or add stuff)
This is probably going to be the case. The thing that could potentially
interest us the most is the media (de)multiplexing part and we'd
probably need to adapt it to our structure.
you can work on the
media server or maintain a derived branch without any problems.
Great, thanks for letting us know! We'll keep that in mind when we start
working on conferencing.
BTW, I am looking into bootstrapping SIP communicator inside eclipse as
a debugging tool for telco services, do you have any plans to completely
separate the SIP part from the UI (no UI dependencies in the protocol
This should actually be the case already. The unit tests for example
launch SIP Communicator and make it connect to various networks without
ever needing the UI. There is indeed a dependency on the service.gui
package but we only need that one in the UriHandler (the class that
handles "sip:" addresses that are passed as launch args). We only use it
to notify the user in case something wrong happens, like for example a
malformed URI. Since you probably won't need such functionality in the
use cases you mention, the easiest fix would be to simply remove the
UriHandler class. As a matter of fact you could even keep it in there
and it would simply never be used.
A more proper resolution would involve moving the uri handler our of the
SIP package and into a separate plugin. Anyone willing to contribute?
This change would allow sip communicator to be used for many
other applications like a multiplatform java alternative to sipp and an
open source alternative to Kitcat and others.
On Fri, Feb 27, 2009 at 2:52 PM, Lubomir Marinov > <email@example.com <mailto:firstname.lastname@example.org>> wrote:
Thank you! Your proposal sounds very appealing and I'll be sure to
examine the conferencing part of Mobicents Media Server and how it can
be of help for the respective implementation in SIP Communicator.
About replacing our RTP layer with your product, my initial feeling is
that it would be better to at least try to keep it outside the SIP
Communicator project and it currently means into JMF. Anyway, I still
have to look into it in order to get an informed opinion.
Another thing I'm not quite clear about at this time is the licensing.
Going by your downloads page, it seems Mobicents Media Server is
released under the GPL. SIP Communicator uses the LGPL. I admit I'm
not knowledgeable in the area of licenses, let alone mixing them
but... How will these two play together? Is there a way to get what we
need from Mobicents Media Server under the terms of the LGPL instead
of the GPL?
On Thu, Feb 26, 2009 at 9:26 PM, Vladimir Ralev > <email@example.com <mailto:firstname.lastname@example.org>> wrote:
> Hi guys,
> Here is an idea from the Mobicents team. There is a Mobicents
> which is an isolated entity purely responsible for RTP. I think
> completely replace your RTP layer with this media server and
> the feature it provides - local call mixing/conferencing, call
> answering machine or other auto-response features. I would say the
> server is pretty light-weight - small and boot-time should be less
> second and it is already able to handle hunders of calls, so
> mode should not be a problem at all. The media server supports the
> codecs, except for video and lbc, but they can be added and if
> I think you won't miss any of your current features. Also there is
no jmf or
> fmj dependencies in the media server and for now everything is
To unsubscribe, e-mail:
For additional commands, e-mail:
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org