2009/8/24 Daniel-Constantin Mierla miconda@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.