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