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.
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? Which would be the difference between choosing SR, Kamailio (with SR code) or SER (with SR core) to build a SIP platform?
Other question: If there would be a new and more advanced presence module for Kamailio, would it automaticaly be integrated in SR?
Thanks for your time explaining it :)