[sip-comm-dev] Mobicents Media Server for the RTP layer


#1

Hi guys,

Here is an idea from the Mobicents team. There is a Mobicents Media Server
which is an isolated entity purely responsible for RTP. I think you can
completely replace your RTP layer with this media server and benefit from
the feature it provides - local call mixing/conferencing, call recording,
answering machine or other auto-response features. I would say the media
server is pretty light-weight - small and boot-time should be less than a
second and it is already able to handle hunders of calls, so single-call
mode should not be a problem at all. The media server supports the usual
codecs, except for video and lbc, but they can be added and if this happens
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 pure Java.


#2

Hi Vladimir,

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?

Regards,
Lubo

···

On Thu, Feb 26, 2009 at 9:26 PM, Vladimir Ralev <vladimir.ralev@gmail.com> wrote:

Hi guys,

Here is an idea from the Mobicents team. There is a Mobicents Media Server
which is an isolated entity purely responsible for RTP. I think you can
completely replace your RTP layer with this media server and benefit from
the feature it provides - local call mixing/conferencing, call recording,
answering machine or other auto-response features. I would say the media
server is pretty light-weight - small and boot-time should be less than a
second and it is already able to handle hunders of calls, so single-call
mode should not be a problem at all. The media server supports the usual
codecs, except for video and lbc, but they can be added and if this happens
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 pure Java.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

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) you can work on the media server
or maintain a derived branch without any problems.

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 code)?
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 <lubomir.marinov@gmail.com>wrote:

Hi Vladimir,

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?

Regards,
Lubo

On Thu, Feb 26, 2009 at 9:26 PM, Vladimir Ralev > <vladimir.ralev@gmail.com> wrote:
> Hi guys,
>
> Here is an idea from the Mobicents team. There is a Mobicents Media
Server
> which is an isolated entity purely responsible for RTP. I think you can
> completely replace your RTP layer with this media server and benefit from
> the feature it provides - local call mixing/conferencing, call recording,
> answering machine or other auto-response features. I would say the media
> server is pretty light-weight - small and boot-time should be less than a
> second and it is already able to handle hunders of calls, so single-call
> mode should not be a problem at all. The media server supports the usual
> codecs, except for video and lbc, but they can be added and if this
happens
> 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 pure Java.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hey Vladimir,

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
code)?

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?

Cheers
Emil

···

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 > <lubomir.marinov@gmail.com <mailto:lubomir.marinov@gmail.com>> wrote:

    Hi Vladimir,

    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?

    Regards,
    Lubo

    On Thu, Feb 26, 2009 at 9:26 PM, Vladimir Ralev > <vladimir.ralev@gmail.com <mailto:vladimir.ralev@gmail.com>> wrote:
    > Hi guys,
    >
    > Here is an idea from the Mobicents team. There is a Mobicents
    Media Server
    > which is an isolated entity purely responsible for RTP. I think
    you can
    > completely replace your RTP layer with this media server and
    benefit from
    > the feature it provides - local call mixing/conferencing, call
    recording,
    > answering machine or other auto-response features. I would say the
    media
    > server is pretty light-weight - small and boot-time should be less
    than a
    > second and it is already able to handle hunders of calls, so
    single-call
    > mode should not be a problem at all. The media server supports the
    usual
    > codecs, except for video and lbc, but they can be added and if
    this happens
    > 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
    pure Java.
    >

    ---------------------------------------------------------------------
    To unsubscribe, e-mail:
    dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    For additional commands, e-mail:
    dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi!

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) you
can work on the media server or maintain a derived
branch without any problems.

At least as far as I understand the GPL compatibility matrix
(http://www.fsf.org/licensing/licenses/gpl-faq.html#AllCompatibility),
using GPL code or a GPL library in a LGPL project is not possible. The
only way would be for SIP Communicator to move to GPL, but that would
possibly cause licensing problems with other libraries.

Cheers
Michael Koch

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hello,

When trying to access debug SIP registrar I entered:
sip:michael@10.0.0.2:5070

The SC send the request to the regular 5060 port, without remnoving the port indication from the URI...

INVITE sip:michael@10.0.0.2:5070 SIP/2.0
Call-ID: b68581fa7eca35e2a8880f2903a4a87f@0.0.0.0
CSeq: 1 INVITE

From: <sip:mik111@qms.siptele.com>;tag=c6f866df

Via: SIP/2.0/UDP 10.0.0.4:5060;branch=z9hG4bK7906336774f1df2955ff2692a917ae03
Max-Forwards: 70
User-Agent: SIP Communicator1.0-alpha3-nightly.build.1757Windows XP
Contact: "mik111" <sip:mik111@10.0.0.4:5060;transport=udp;registering_acc=qms_siptele_com>
Content-Type: application/sdp
Content-Length: 237
v=0
o=mik111 0 0 IN IP4 10.0.0.4
s=-
c=IN IP4 10.0.0.4
t=0 0
m=audio 5000 RTP/AVP 0 3 5 4
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no;bitrate=6.3
m=video 5002 RTP/AVP 99 34 26
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=1

···

To: <sip:michael@10.0.0.2:5070>


#7

Hey mik,

Are you using an outbound proxy? If yes then SC would send anything to
the address and port of the proxy regardless of the URI you are trying
to reach.

Cheers
Emil

mik wrote:

···

Hello,

When trying to access debug SIP registrar I entered:
sip:michael@10.0.0.2:5070

The SC send the request to the regular 5060 port, without remnoving the
port indication from the URI...

INVITE sip:michael@10.0.0.2:5070 SIP/2.0
Call-ID: b68581fa7eca35e2a8880f2903a4a87f@0.0.0.0
<mailto:b68581fa7eca35e2a8880f2903a4a87f@0.0.0.0>
CSeq: 1 INVITE
From: <sip:mik111@qms.siptele.com>;tag=c6f866df
To: <sip:michael@10.0.0.2:5070>
Via: SIP/2.0/UDP
10.0.0.4:5060;branch=z9hG4bK7906336774f1df2955ff2692a917ae03
Max-Forwards: 70
User-Agent: SIP Communicator1.0-alpha3-nightly.build.1757Windows XP
Contact: "mik111"
<sip:mik111@10.0.0.4:5060;transport=udp;registering_acc=qms_siptele_com>
Content-Type: application/sdp
Content-Length: 237
v=0
o=mik111 0 0 IN IP4 10.0.0.4
s=-
c=IN IP4 10.0.0.4
t=0 0
m=audio 5000 RTP/AVP 0 3 5 4
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no;bitrate=6.3
m=video 5002 RTP/AVP 99 34 26
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=1

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net