[Kamailio-Users] [SR-Users] kamailio 3.0 - the time before freezing
Iñaki Baz Castillo
ibc at aliax.net
Tue Aug 25 01:01:57 CEST 2009
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 :)
--
Iñaki Baz Castillo <ibc at aliax.net>
More information about the Users
mailing list