[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 sr-users mailing list