[sr-dev] [SR-Users] [Kamailio-Users] kamailio 3.0 - the time before freezing

[Iñaki Baz Castillo]

2009/8/24 Daniel-Constantin Mierla <miconda at gmail.com>:

> I am personally aware of companies using Kamailio with several millions of
> subscribers, using kamailio database schema. Also, I am aware of companies
> having more or less same level of subscriber base using SER database schema.
> All have additional tools for management, integration with third-party
> application, a.s.o. Do you think that saying "hey, you were the unlucky
> bastard because we are going to drop tomorrow the database schema you are
> using" is the solution?

That's right, but I don't expect that migration to SR is a priority
for those companies already using OpenSER/Kamailio. For example, I
know some companies still using OpenSer 1.2.

However, it seems that the idea is that Kamailio/SER will use SR as
core, but the fact is that SR core uses current Kamailio and SER
modules/features as separate (modules_k, modules_s...). Wouldn't make
sense to unify SR code instead of having it splited in K and S? AFAIK
this is the idea for a future, but in the meanwhile I don't fully
understand why SR requires to run right now as it is.


>> What I don't understand is the reasons to make current SR working with
>> K and S features/modules compatibility. We don't need a SR working
>> solution right now (since Kamailio and SER do exist), do we?
>
> Maybe not you, but there are others. I am facing many troubles because of
> TCP (also TLS) layer in K which do not happen with SR core - asynchronous
> TCP helps a lot.

Sure that's a good reason :)
But again you are speaking about Kamailio using SR as core (new and
improved TM module) while I meant SR code itself (which for now is a
mostly separate mix between K and S code instead of an unified
technology).


> All (but seas) are ported.

Perhaps I understand it wrongly, but IMHO the modules will be really
ported when there is a unique MI interface for all of them (instead of
having to use K MI for K modules and S MI for S modules), when there
are just an unique class of pseudovariables (instead of having K and S
pvs)...


Regards.


-- 
Iñaki Baz Castillo
<ibc at aliax.net>