On 25.08.2009 2:01 Uhr, Iñaki Baz Castillo wrote:
El Lunes, 24 de Agosto de 2009, Daniel-Constantin Mierla escribió:
. Wouldn't be better to spent devel time in porting the required K/S modules to SR instead of making them working as K/S modules in any way?
All (but seas) are ported. There is nothing else to port, just some overlapping (read conflicting) from functionality/database structure point of view.
Ok, got the point, thanks for the explanation. Just a question about modules/functions overlapping:
Right now there are a lot of modules (even more in SR as it has K and S modules). There are modules with function names like "to_gw", "from_gw", "check_to"... From a user perspective is really difficult to guess which function belongs to a module. Also, due to similar modules in K and S there could be funtion namming conflicts. Wouldn't make sense to prefix each function with the module name? Something as: lcr.to_gw uri.check_to
There coulb be other options of course.
this is a general issue, some discussions were undertaken on mailing list, probably will be addressed more specific in the near future.
You can do your Inakilio SIP server
Ops, purchasing the domain right now :)
using ser auth module and kamailio location/presence modules if that suits better. Kamailio has to provide to its users of version 1.5.x a new release on the same line of modules.
This is the only point I have no 100% clear: will Kamailio next release contain K and S modules since it uses SR? or just K modules?
All K modules plus any of S modules that is interesting and does not overlap with a K module. Still to be selected, but that is the main guideline of selection.
Which would be the difference between choosing SR, Kamailio (with SR code) or SER (with SR core) to build a SIP platform?
Needed modules. There are quite some inter-module dependencies and differences of features.
Other question: If there would be a new and more advanced presence module for Kamailio, would it automaticaly be integrated in SR?
Everything new is integrated to SR - there is one repository for everything. Other modules will get merged, so overlapping is going to be less and less, but not removed at once - for example, sl, cpl-c, pike, maxfwd, ... modules do not depend much on db layer that holds back integration in one -- so actually, next step is to take one by one and see what can be done.
Cheers, Daniel