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

Daniel-Constantin Mierla miconda at gmail.com
Mon Aug 24 15:24:55 CEST 2009



On 24.08.2009 15:57 Uhr, Iñaki Baz Castillo wrote:
> 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.
>   
yes, I do, even older, I have a ser 0.9.4 somewhere and no plan to 
upgrade it. It has 1 year 4 months without restart.


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

some modules were moved under "modules" directory. The ones that have 
names overlapping and inter-dependencies are going to stay in separate 
directories.

>  Wouldn't make
> sense to unify SR code instead of having it splited in K and S?

probably you misunderstood something. The code is unified, but SR has 
support to hold modules in more than one directory. Now the structure is 
based on origin (again, the reason is name overlapping), but in the 
future could be:

modules_presence
modules_db

IIRC, there are over 150 modules all together, so better structuring 
might be necessary.

>  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).
>   
I don't get it. Maybe you can rephrase/detail what is 
misleading/confusing you. The existence of 3 module directories? 
Everything is unified, one source repository, one project, if you think 
just to SR environment.

>> 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),
Using RPC interface gives access to MI commands -- so ser guys are the 
first lucky :-). However, let's get back to the root:
- there are modules implementing MI
- there are modules implementing RPC interface
- there are modules implementing none
- there might be modules implementing both

Where to position a module is just a matter of developers. Similar 
choise is for  regular expressions - use posix or pcre library - 
database - use interface v1 or v2 (which has prepared statements 
support) - and examples can continue. I see ability to choose a great 
feature.

>  when there
> are just an unique class of pseudovariables (instead of having K and S
> pvs)...
>   
Here is only one: config file variables - how they are referred in mails 
is a different story, to better indentify and reflex origin, but all can 
be used in config file. Actually, the group referred K PVs have classes.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
* http://www.asipto.com/





More information about the sr-users mailing list