2009/8/24 Daniel-Constantin Mierla <[email protected]>: > 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 <[email protected]> _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
