Hello,
On 24.08.2009 14:14 Uhr, Alex Balashov wrote:
The
sip-router.org documentation is already
excessively complicated
and difficult to understand for anyone who does not routinely work
with both the K and S code. At this point, the documentation, while
voluminous, is overwhelming and, in places, woefully incomplete,
can you point such
places?
while in other places, I would say
"exhaustively" (perhaps
"exhaustingly") complete.
From K point of view, same documentation is available, the core, pv and
transformations cookbooks are updated completely -- actually only core
cookbook needed a major update since we had a lot of new parameters for
dns, transport layers, etc...
All of this confusion - starting with the fundamental difference
between K and SR, which nobody *I* know in the user community yet
understands in any level of substance or detail
Kamailio is the same -- will be a new major release of the sip server
everybody know so far -- new features in core plus some new modules,
either new development (memcache) or imported from ser (iptrtproxy). To
update from kamailio 1.5 to 3.0 you will need, as usual, some db
structure updates (not much afaik - lcr module, maybe cr) and some
updates to config file syntax (minimal as well for most of usage cases).
Your questions can be rephrased as "what is the difference between linux
and debian?". Debian is just a particular packaging of available linux
applications. In similar way, Kamailio, is SR core plus selection of SR
modules. Like in linux, where are application that overlap in
functionality, and one is preferred over the others (e.g., MTA), in SR
there are modules that overlap (e.g., auth) using a different
concept/database structure and one is preferred to the other.
I also encounter the widespread perception from my
customers that a
lot of time has been spent on "fun"
I would have liked some fun, but
there wasn't, not for me, very
interesting perception I would say, maybe you can point me such cases.
It was quite heavy work. The goal of trying to preserve max
compatibility while not messing up a lot of code in core was achieved -
the core impact was kept minimal, therefore inheriting stability from
ser 2.0. Several modules took the load of extra features.
and "interesting" integration work, not on
developing features or
fixing bugs. I hope they're wrong.
What are the bugs staying unfixed? What are
missing features not
adopted? There was quite a lot of new development, including transport
layer such as sctp, asyncronous message processing (t_suspend/t_continue
which is functional), continuing with new modules (link provided in
previous email).
Cheers,
Daniel
--
Daniel-Constantin Mierla
*
http://www.asipto.com/