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

[MÉSZÁROS Mihály]

Klaus Darilion wrote:
>
>
> 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.
>
Hi!

I want only mention my experience. (I am pretty new using sip-router.)
I tried to mix the modules but it didn't work for me.
So I want some modules from modules_s (xlog,auth_identiy ...) and other 
from modules_p (presence etc.)
But i have failed. :(
I must choose from the two repository. I can't use it together.
The key problem was that SL modul is not merged. Many modules depends on 
this modul.

Misi
> 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.
>>
>>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev