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

[Klaus Darilion]

Iñaki Baz Castillo schrieb:
> 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? 

I always is a matter of viewpoint (If A sits next to B, B also sits next 
to A). Of course you could have it in 3 repositories: 1xSR, 1xser and 
1xKamailio. But the decision was to use a single repository for easier 
developing (e.g. core API changes require module changes too).

So, at the moment SR is the common repository for Kamailio 
(modules_k+modules+core) and ser (modules_s+modules+core). So, I think 
the next Kamailio release (source ball) might have just modules_k and 
modules. And ser does not need to distribute modules_k. However, if 
somebody wants to make fine selection, modules_s and modules_k can be 
mixed too.

regards
Klaus


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.
> 
>