oSIP news

[jack]

Rich, Dyfet, David and anonymous,

First:
I'm Aymeric, the Author of oSIP. I've been waiting
for my copyright disclaimer for a while now and my
previous company just told me last week, that they signed
it and were about to send it... So oSIP is nearly GNU.

Second:
Rich, you mention: "There are plenty of GPL'd SIP stacks out there"
What???
Vovida: This code can fit SIP User Agent implemetation. (if you like
C++) but I do not think it could be used for high available servers.
(This is only my personnal opinion. You have access to the source,
check it....)
Dissipate: A GPL and very tiny implementation, I asked the author about
it: here is his personnal comment from the mail we exchanged today:
"I did shit fuck all."
I've heard about a future Java Implementation from an american
institute, but I don't know more... Also, Java may not be the
solution for GNUComm!

Now the oSIP stack:
C based, the parser is "100112 octets" and the finite state
machines (uasble for User Agent, Registrar and redirect server)
is 34512 octets. It runs quite fast and is really stable.
Some features are missing... A finite state machine for proxy,
some hole in the parser (does not support tel url, http url...)

You (dyfet!) may already now that!
What you may not know: linphone is a SIP user agent build on
oSIP. The application is now working quite good and has basics
SIP features (4 codecs, SIP digest authentication (not fully tested)
busy, DND, back in X minutes and redirection modes) Some issue
remains mainly with proxy as we jujst don't have enough materials to
test with...)

Also, I've build a very basic registrar and redirect server for
SIP. It's called osrd and is registred since last week on savannah.
It's very basic by now and surely not scalable, but this is just
a start! Nevertheless, it's working great with linphone for a small
amount of users.

I hope I'll get my diclaimer this week. Anyway, this does not
change the fact that it's LGPL...
Cheers,
Aymeric


> David,
> 
>       There is not much development going on in the GNUComm
>       architecture at the moment.  GNUComm is a very ambitious,
>       long-term project, that will be most practically useful in
>       coordinating the development of several individually useful
>       programmable servers.  The idea is that these servers, such as
>       Bayonne, will be required to interoperate and, in some cases,
>       share application code.  To help that happen, documentation,
>       applications and libraries coordination will be developed in
>       GNUComm.  We have a roadmap, but the only completed server
>       that is in use at the moment is Bayonne.
> 
>       As far as choosing a gatekeeper.  I don't think H.323 will
>       re-license, but that's not a problem.  We can still
>       communicate with non-gnu software, we just can't link with
>       it.  There are plenty of GPL'd SIP stacks out there, so they
>       may be more helpful in the long term.  I'm more concerned at
>       the moment with getting Bayonne apps developed, but scratch
>       your own itch.  If you've got some ideas or some code, I'd be
>       happy to put it in a contrib section.
> 
>       When I say I want to allow the user with low-end hardware an
>       option, I am, of course, being practical.  If you take care in
>       the design, it is possible to add support for say, voice
>       modems, to an enterprise class application.
> 
>       Working with GNUe is a long-term goal, primarily to share
>       application and data objects.
> 
>       As far as scalability and monitoring are concenred, that's
>       what the various data buses are for in the architecture
>       diagram.  Bayonne already has an experimental data-redundancy
>       bus, and there has been some work done on the trip server.  We
>       have to crawl before we can walk, though.
> 
> -Rich
> 
> Rich Bodo | address@hidden | 650-964-4678
> 
> On Tue, 15 Jan 2002, David wrote:
> 
>> I am trying to understand some more about gnucomm.
>>
>> I was wondering if I could ask some questions. I have read most of the
>> information that I can find and would like to clarify a few things.
>>
>> Your http://www.gnu.org/software/gnucomm/overview.html document
>> indicates that you will have a gatekeeper. Have you approached
>> openH323 with respect to either re-licensing or even dual licensing
>> their Open H323 software? Would this in fact help? I would have
>> thought it would provide not only a basic protocol stack but a number
>> of other associated programs covering both protocol monitoring and end
>> point clients.
>>
>> On the topics of Service activation and service assurance does the
>> GNUe initiative have applications or structures here that will be used
>> or are you looking at something new? You mention that the
>> configuration should be simply to the end user and that low end
>> computing power should not be a barrier to entry but i was wondering
>> how you were going to build scalability. Configuring new services and
>> then monitoring one machine to see that it is performing correctly but
>> what about 300 machines all with different versions of software and
>> different prompts. Is there any planned mechanism to manage a very
>> large and diverse network?
>>
>> I trust these questions are not bothersome but I am somewhat looking
>> for answers. I checked out the source tree but I am not a programmer
>> so I was looking for documentation of which I didn't find alot and
>> wasn't able to understand the source tree all that well.
>>
>> Thankyou for any help you can give me.
>>
>> Best Regards,
>>
>> David Price
>>
>> _______________________________________________
>> Help-gnucomm mailing list
>> address@hidden
>> http://mail.gnu.org/mailman/listinfo/help-gnucomm
>>
> 
> 
> _______________________________________________
> Help-gnucomm mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/help-gnucomm