24 Aug
2009
24 Aug
'09
10:26 a.m.
Iñaki Baz Castillo schrieb:
2009/8/24 Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
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
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? 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.
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).
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. 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.