24 Aug
2009
24 Aug
'09
12:02 p.m.
Hello everybody,
during the last IRC devel meeting, we pinned end of summer to be the
time to enter testing phase for the new major release - codenamed
kamailio 3.0.
There was quite a lot of brand new features, considering that most of
devel effort was directed to integration. A try to collect new items is
available at:
http://sip-router.org/wiki/features/new-in-devel
Of course, all ser features are available as well, resulting a large
amount of new stuff in kamailio 3.0 vs kamailio 1.5.x. See:
http://sip-router.org/benefits/
http://www.iptel.org/ser/features
I propose to start the testing phase sometime next week.
Meanwhile, let's see if something important was forgotten from kamailio
core or tm. To my knowledge:
- path support in tm - Andrei has it on his todo afaik - in a way or
another, it must get in next release
- drop compatibility - drop reply in reply_route - internally drop and
exit are now differentiated by core, needs review and update of handling
after running the routes - on my to-do
Apart seas, all Kamailio modules are fully ugraded to new core - I
started but lack of test env + busy summer resulted in delays - can be
done during testing period, being just api updates.
If you have discovered something else, let us know.
Thanks,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
24 Aug
24 Aug
12:47 p.m.
New subject: [Kamailio-Users] kamailio 3.0 - the time before freezing
Daniel-Constantin Mierla writes:
If you have discovered something else, let us know.
well, just before your message i send a question to andrei about async
(or delayed reply) support for t_uac_dlg. without that i'm not able to
start using sip router, because having to use two xmlrpc management
interfaces to manage one proxy is not acceptable to me.
-- juha
12:52 p.m.
Hello,
On 24.08.2009 13:47 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
that is a new features for RPC interface in ser. Probably Andrei will do
it if he committed to, but don't take my answer on his behalf, my
knowledge about RPC interface is now very broad right now.
You can still use one interface though - MI is fully available and does
(pseudo) async xmlrpc commands.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
If you have discovered something else, let us
know.
well, just before your message i send a question to andrei about async
(or delayed reply) support for t_uac_dlg. without that i'm not able to
start using sip router, because having to use two xmlrpc management
interfaces to manage one proxy is not acceptable to me.
12:53 p.m.
On 24.08.2009 13:52 Uhr, Daniel-Constantin Mierla wrote:
Hello,
On 24.08.2009 13:47 Uhr, Juha Heinanen wrote:
^^^ is not very ...
Daniel
Daniel-Constantin Mierla writes:
that is a new features for RPC interface in ser. Probably Andrei will
do it if he committed to, but don't take my answer on his behalf, my
knowledge about RPC interface
is now very broad right now. If you have discovered something else, let us
know.
well, just before your message i send a question to andrei about async
(or delayed reply) support for t_uac_dlg. without that i'm not able to
start using sip router, because having to use two xmlrpc management
interfaces to manage one proxy is not acceptable to me.
You can still use one interface though - MI is fully available and
does (pseudo) async xmlrpc commands.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
12:58 p.m.
Daniel-Constantin Mierla writes:
You can still use one interface though - MI is fully
available and does
(pseudo) async xmlrpc commands.
that is not true if you use modules from both s and k (like domain
domain module, for example, that is much more advanced in s).
besides, s xmlrpc interface is much better that k's, because it each
call executes a config file route block, that allows (among other things)
access control.
-- juha
1:08 p.m.
On 24.08.2009 13:58 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
ok, I see. Solutions:
- stress Andrei and/or other RPC devels :-)
- add missing/needed MI commands to s modules
I am considering merging sl module -- seems to be one preventing using
easy some modules from both sides.
You can still use one interface though - MI is
fully available and does
(pseudo) async xmlrpc commands.
that is not true if you use modules from both s and k (like domain
domain module, for example, that is much more advanced in s).
besides, s xmlrpc interface is much better that
k's, because it each
call executes a config file route block, that allows (among other things)
access control.
With this one I agree.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
1:14 p.m.
Please be careful amidst all this to remember that this "integration"
could be the undoing of the Kamailio/SR project, and may drive people to
OpenSIPS. In the end, it is the users that matter.
The sip-router.org documentation is already excessively complicated and
difficult to understand for anyone who does not routinely work with both
the K and S code. At this point, the documentation, while voluminous,
is overwhelming and, in places, woefully incomplete, while in other
places, I would say "exhaustively" (perhaps "exhaustingly") complete.
All of this confusion - starting with the fundamental difference between
K and SR, which nobody *I* know in the user community yet understands in
any level of substance or detail - is starting to make OpenSIPS look
very straightforward and self-evident. You don't want this.
I also encounter the widespread perception from my customers that a lot
of time has been spent on "fun" and "interesting" integration work,
not
on developing features or fixing bugs. I hope they're wrong.
--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
1:32 p.m.
New subject: [Kamailio-Users] kamailio 3.0 - the time before freezing
2009/8/24 Alex Balashov <abalashov(a)evaristesys.com>om>:
Please be careful amidst all this to remember that
this "integration" could
be the undoing of the Kamailio/SR project, and may drive people to OpenSIPS.
In the end, it is the users that matter.
The sip-router.org documentation is already excessively complicated and
difficult to understand for anyone who does not routinely work with both the
K and S code. At this point, the documentation, while voluminous, is
overwhelming and, in places, woefully incomplete, while in other places, I
would say "exhaustively" (perhaps "exhaustingly") complete.
All of this confusion - starting with the fundamental difference between K
and SR, which nobody *I* know in the user community yet understands in any
level of substance or detail - is starting to make OpenSIPS look very
straightforward and self-evident. You don't want this.
I also encounter the widespread perception from my customers that a lot of
time has been spent on "fun" and "interesting" integration work, not
on
developing features or fixing bugs. I hope they're wrong.
I must agree with Alex.
Sincerely I will wait until SR is really released to start with it.
And with "really released" I mean: when both kamailio and SER concepts
disapear entirely from SR (no more K/S-modules, K/S-functions,
K/S-components, K/S-pseudovariables, no more compability features and
so on).
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?. Wouldn't
be better to spent devel time in porting the required K/S modules to
SR instead of making them working as K/S modules in any way?
Please, don't take me wrong, I just wonder what's the rush to have a
SR working instead of having a real an independent SR release :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
1:44 p.m.
New subject: [Kamailio-Users] kamailio 3.0 - the time before freezing
Iñaki Baz Castillo wrote:
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?. Wouldn't
be better to spent devel time in porting the required K/S modules to
SR instead of making them working as K/S modules in any way?
I think the idea is that SR is a common layer - sort of like a kernel -
from which subsequent features are derived in both K and S.
What this fails to explain in any way is what the intended applications
of K vs. SR are from an end-user perspective.
--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
1:51 p.m.
New subject: [Kamailio-Users] [sr-dev] kamailio 3.0 - the time before freezing
Alex Balashov wrote:
What this fails to explain in any way is what the intended
applications of K vs. SR are from an end-user perspective.
There is quite some substantial differences between SER 2.x and
Kamailio. However, they are at a level further up -- most importantly
completely different database schemas. Thus it makes sense to merge the
core, which is mostly compatible between SER and Kamailio, and make two
different bundles that allow people coming from Kamailio to continue
using their tested and proven configs and the same for people using SER.
Eventually, the difference will go away, but for starters this really is
the smartest way to get people to use SIP Router -- without them
actually knowing it.
Regards,
Martin
1:54 p.m.
New subject: [Kamailio-Users] [sr-dev] kamailio 3.0 - the time before freezing
Martin Hoffmann wrote:
Alex Balashov wrote:
Perhaps. But, building in a mandatory premise of (nontrivial) future
change as part of "eventually, the difference will go away" is not
attractive.
--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
What this fails to explain in any way is what the
intended
applications of K vs. SR are from an end-user perspective.
There is quite some substantial differences between SER 2.x and
Kamailio. However, they are at a level further up -- most importantly
completely different database schemas. Thus it makes sense to merge the
core, which is mostly compatible between SER and Kamailio, and make two
different bundles that allow people coming from Kamailio to continue
using their tested and proven configs and the same for people using SER.
Eventually, the difference will go away, but for starters this really is
the smartest way to get people to use SIP Router -- without them
actually knowing it.
1:46 p.m.
New subject: [Kamailio-Users] kamailio 3.0 - the time before freezing
Iñaki Baz Castillo writes:
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?. Wouldn't
be better to spent devel time in porting the required K/S modules to
SR instead of making them working as K/S modules in any way?
this is exactly how i also like it to be and which was discussed a
couple of months ago on the mailing list. i would have liked to have
sip-router, not k or s version of it, but officially it didn't go that
way.
-- juha
2:05 p.m.
New subject: [Kamailio-Users] kamailio 3.0 - the time before freezing
On 24.08.2009 14:32 Uhr, Iñaki Baz Castillo wrote:
I must agree with Alex.
Sincerely I will wait until SR is really released to start with it.
And with "really released" I mean: when both kamailio and SER concepts
disapear entirely from SR (no more K/S-modules, K/S-functions,
K/S-components, K/S-pseudovariables, no more compability features and
so on).
Well, this is not easy as you may think. Even easier from coding point
of view, the management of any relevant project around the world has to
take in consideration backward compatibility and easy upgrades.
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?
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. I use memcache and plan to move all server
to server communication to SCTP for reliability and HA. Using
asynchronous processing (t_suspend/t_continue) I am able to get a very
scalable routing and billing engine (prepaid) which is no way possible
with other technologies.
. Wouldn't
be better to spent devel time in porting the required K/S modules to
SR instead of making them working as K/S modules in any way?
All (but seas) are ported. There is nothing else to port, just some
overlapping (read conflicting) from functionality/database structure
point of view. You can do your Inakilio SIP server using ser auth module
and kamailio location/presence modules if that suits better. Kamailio
has to provide to its users of version 1.5.x a new release on the same
line of modules.
Cheers,
Daniel
Please, don't take me wrong, I just wonder
what's the rush to have a
SR working instead of having a real an independent SR release :)
--
Daniel-Constantin Mierla
* http://www.asipto.com/
2:08 p.m.
New subject: [Kamailio-Users] kamailio 3.0 - the time before freezing
Daniel-Constantin Mierla wrote:
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 true.
We can say that there should be one unified code body all we want, but,
at the very least we need to acknowledge that the problem is not nearly
as simple as it looks on the surface.
--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
2:54 p.m.
New subject: [Kamailio-Users] kamailio 3.0 - the time before freezing
On 24.08.2009 15:08 Uhr, Alex Balashov wrote:
Daniel-Constantin Mierla wrote:
if you refer to merging "duplicated" modules, could not be a solution
anyhow. In the past, there were some events generating hot discussions
when trying to force/limit to one way of doing things.
The preliminary discussions for sip router project concluded that there
must be freedom of contributors with fair control of original developer.
Core, tm are sensitive parts and so called "common layer" where any
piece of code getting in is carefully reviewed.
Otherwise, if there is a conflict in licensing, between developers of
same piece of code, creating a new module/library is the way to go. This
does not mean everyone can spin off new modules, but if the contribution
is relevant, has support from community members, it must get in.
I see no reason of having modules for same functionality (e.g., say
authentication) as long as each such module has maintainers. Time should
prove which is better and obsolete the others, but also, each could be
more suitable for a particular case.
Just as a different example, sqlops plus some scripting could obsolete
most of db-connected modules - auth_db, alias_db, speeddial, uri_db,
a.s.o, but doing so is not at all a good decision.
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 true.
We can say that there should be one unified code body all we want, but, at the very least we need to
acknowledge that
the problem is not nearly as simple as it looks on the surface.
Nothing is simple :-) . Also, I admit that any integration work rises
controversy, which may create some degree of confusion. But all
discussions were constructive so far, nothing was dismissed and the way
things blended so far proves the flexibility level we achieved: keep the
core and tm small and stable, build around with modules and libraries so
that the impact is minimal for those not using the stuff that just got in.
From my point of view, integration went smooth, but with higher work
volume that anticipated, since both projects really had a lot of new
features (some better documented, some not).
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
3:29 p.m.
New subject: [Kamailio-Users] kamailio 3.0 - the time before freezing
Daniel-Constantin Mierla wrote:
Just as a different example, sqlops plus some
scripting could obsolete
most of db-connected modules - auth_db, alias_db, speeddial, uri_db,
a.s.o, but doing so is not at all a good decision.
In the case of my implementations, I have to do this quite frequently
because I do custom integration projects that incorporate specific
providers' sometimes very esoteric business logic. The sqlops module
was one of the best things to ever have happened to Kamailio, and I am
very thankful for it.
My understanding is that the argument for using a native DB-connected
module boils down to the fact that most of these modules do some sort of
in-memory caching and/or buffering of large data sets, and use data
structures and search algorithms that are appropriate to the nature of
that data. So, this results in much faster processing with less
overhead and, of course, less database load.
I try to use them whenever possible. But sometimes it is not, which is
why I am very grateful for the thought that went into creating
parameters like this:
http://www.kamailio.org/docs/modules/1.5.x/auth.html#id2505013
-- Alex
--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
3:37 p.m.
New subject: [Kamailio-Users] kamailio 3.0 - the time before freezing
On 24.08.2009 16:29 Uhr, Alex Balashov wrote:
Daniel-Constantin Mierla wrote:
No, no caching for above mentioned
modules. They simply hide a db query
in most of the cases. They are supposed to deal with quite large volume
of records where caching makes no sense. So you do not loose any
performance by using sqlops. You can check with benchmark module.
Cheers,
Daniel
Just as a different example, sqlops plus some
scripting could
obsolete most of db-connected modules - auth_db, alias_db, speeddial,
uri_db, a.s.o, but doing so is not at all a good decision.
In the case of my implementations, I have to do this quite frequently
because I do custom integration projects that incorporate specific
providers' sometimes very esoteric business logic. The sqlops module
was one of the best things to ever have happened to Kamailio, and I am
very thankful for it.
My understanding is that the argument for using a native DB-connected
module boils down to the fact that most of these modules do some sort
of in-memory caching and/or buffering of large data sets, and use data
structures and search algorithms that are appropriate to the nature of
that data. So, this results in much faster processing with less
overhead and, of course, less database load.
I try to use them whenever possible. But sometimes it is not, which
is why I am very grateful for the thought that went into creating
parameters like this:
http://www.kamailio.org/docs/modules/1.5.x/auth.html#id2505013
-- Alex
--
Daniel-Constantin Mierla
* http://www.asipto.com/
3:47 p.m.
New subject: [Kamailio-Users] kamailio 3.0 - the time before freezing
Daniel-Constantin Mierla wrote:
No, no caching for above mentioned modules. They
simply hide a db query
in most of the cases. They are supposed to deal with quite large volume
of records where caching makes no sense. So you do not loose any
performance by using sqlops. You can check with benchmark module.
Well, maybe not the above-mentioned modules, but certainly some.
Otherwise, why all the db_mode parameters?
I am thinking here of:
http://www.kamailio.org/docs/modules/1.5.x/dialog.html#id2491994
http://www.kamailio.org/docs/modules/1.5.x/carrierroute.html#id2511124
http://www.kamailio.org/docs/modules/1.5.x/usrloc.html#id2508613
Unless I am misunderstanding these parameters, it seems to me that there
is some performance benefit to using a module with database backing
versus beyond just a wrapper for the queries?
--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
3:53 p.m.
New subject: [Kamailio-Users] kamailio 3.0 - the time before freezing
On 24.08.2009 16:47 Uhr, Alex Balashov wrote:
Daniel-Constantin Mierla wrote:
definitely, yes!
Cheers,
Daniel
No, no caching for above mentioned modules. They
simply hide a db
query in most of the cases. They are supposed to deal with quite
large volume of records where caching makes no sense. So you do not
loose any performance by using sqlops. You can check with benchmark
module.
Well, maybe not the above-mentioned modules, but certainly some. Otherwise, why all the db_mode parameters?
I am thinking here of:
http://www.kamailio.org/docs/modules/1.5.x/dialog.html#id2491994
http://www.kamailio.org/docs/modules/1.5.x/carrierroute.html#id2511124
http://www.kamailio.org/docs/modules/1.5.x/usrloc.html#id2508613
Unless I am misunderstanding these parameters, it seems to me that
there is some performance benefit to using a module with database
backing versus beyond just a wrapper for the queries?
--
Daniel-Constantin Mierla
* http://www.asipto.com/
2:57 p.m.
New subject: [Kamailio-Users] kamailio 3.0 - the time before freezing
2009/8/24 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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 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. 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
<ibc(a)aliax.net>
3:24 p.m.
New subject: [Kamailio-Users] kamailio 3.0 - the time before freezing
On 24.08.2009 15:57 Uhr, Iñaki Baz Castillo wrote:
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.
2009/8/24 Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
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.
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...).
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.
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.
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)...
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/
4:26 p.m.
New subject: [Kamailio-Users] kamailio 3.0 - the time before freezing
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.
5:25 p.m.
New subject: [Kamailio-Users] [sr-dev] kamailio 3.0 - the time before freezing
Klaus Darilion wrote:
Iñaki Baz Castillo schrieb:
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
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.
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? 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.
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).
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev 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.
5:38 p.m.
New subject: [Kamailio-Users] [sr-dev] kamailio 3.0 - the time before freezing
MÉSZÁROS Mihály schrieb:
Klaus Darilion wrote:
Yes, that's true. That's why Daniel said he tries to merge the sl modules
regards
klaus
Iñaki Baz Castillo schrieb:
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. 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.
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?
25 Aug
25 Aug
1:01 a.m.
New subject: [Kamailio-Users] kamailio 3.0 - the time before freezing
El Lunes, 24 de Agosto de 2009, Daniel-Constantin Mierla escribió:
Ok, got the point, thanks for the explanation. Just a question about
modules/functions overlapping:
Right now there are a lot of modules (even more in SR as it has K and S
modules). There are modules with function names like "to_gw",
"from_gw",
"check_to"... From a user perspective is really difficult to guess which
function belongs to a module. Also, due to similar modules in K and S there
could be funtion namming conflicts. Wouldn't make sense to prefix each
function with the module name? Something as:
lcr.to_gw
uri.check_to
There coulb be other options of course.
.
Wouldn't
be better to spent devel time in porting the required K/S modules to
SR instead of making them working as K/S modules in any way?
All (but seas) are ported. There is nothing else to port, just some
overlapping (read conflicting) from functionality/database structure
point of view. You can do your Inakilio SIP server
Ops, purchasing the domain right now :)
using ser auth module
and kamailio location/presence modules if that suits better. Kamailio
has to provide to its users of version 1.5.x a new release on the same
line of modules.
This is the only point I have no 100% clear: will Kamailio next release
contain K and S modules since it uses SR? or just K modules?
Which would be the difference between choosing SR, Kamailio (with SR code) or
SER (with SR core) to build a SIP platform?
Other question: If there would be a new and more advanced presence module for
Kamailio, would it automaticaly be integrated in SR?
Thanks for your time explaining it :)
--
Iñaki Baz Castillo <ibc(a)aliax.net>
9:45 a.m.
New subject: [Kamailio-Users] kamailio 3.0 - the time before freezing
On 25.08.2009 2:01 Uhr, Iñaki Baz Castillo wrote:
All K modules plus any of S modules that is interesting and does not
overlap with a K module. Still to be selected, but that is the main
guideline of selection.
El Lunes, 24 de Agosto de 2009, Daniel-Constantin
Mierla escribió:
Ok, got the point, thanks for the explanation. Just a question about
modules/functions overlapping:
Right now there are a lot of modules (even more in SR as it has K and S
modules). There are modules with function names like "to_gw",
"from_gw",
"check_to"... From a user perspective is really difficult to guess which
function belongs to a module. Also, due to similar modules in K and S there
could be funtion namming conflicts. Wouldn't make sense to prefix each
function with the module name? Something as:
lcr.to_gw
uri.check_to
There coulb be other options of course.
this is a general issue, some discussions were undertaken on mailing
list, probably will be addressed more specific in the near future.
.
Wouldn't
be better to spent devel time in porting the required K/S modules to
SR instead of making them working as K/S modules in any way?
All (but seas) are ported. There is nothing else to port, just some
overlapping (read conflicting) from functionality/database structure
point of view.
You can do
your Inakilio SIP server
Ops, purchasing the domain right now :)
using ser auth module
and kamailio location/presence modules if that suits better. Kamailio
has to provide to its users of version 1.5.x a new release on the same
line of modules.
This is the only point I have no 100% clear: will Kamailio next release
contain K and S modules since it uses SR? or just K modules?
Which would be the difference between choosing SR,
Kamailio (with SR code) or
SER (with SR core) to build a SIP platform?
Needed modules. There are quite some inter-module dependencies and
differences of features.
Other question: If there would be a new and more
advanced presence module for
Kamailio, would it automaticaly be integrated in SR?
Everything new is integrated to SR - there is one repository for
everything. Other modules will get merged, so overlapping is going to be
less and less, but not removed at once - for example, sl, cpl-c, pike,
maxfwd, ... modules do not depend much on db layer that holds back
integration in one -- so actually, next step is to take one by one and
see what can be done.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
10:47 a.m.
New subject: [Kamailio-Users] kamailio 3.0 - the time before freezing
2009/8/25 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Great, now 100% understood :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Other
question: If there would be a new and more advanced presence module
for Kamailio, would it automaticaly be integrated in SR?
Everything new is integrated to SR - there is one repository for everything.
Other modules will get merged, so overlapping is going to be less and less,
but not removed at once - for example, sl, cpl-c, pike, maxfwd, ... modules
do not depend much on db layer that holds back integration in one -- so
actually, next step is to take one by one and see what can be done.
24 Aug
24 Aug
1:43 p.m.
New subject: [Kamailio-Users] [sr-dev] kamailio 3.0 - the time before freezing
Hello,
On 24.08.2009 14:14 Uhr, Alex Balashov wrote:
The sip-router.org documentation is already
excessively complicated
and difficult to understand for anyone who does not routinely work
with both the K and S code. At this point, the documentation, while
voluminous, is overwhelming and, in places, woefully incomplete,
can you point such
places?
while in other places, I would say
"exhaustively" (perhaps
"exhaustingly") complete.
From K point of view, same documentation is available, the core, pv and
transformations cookbooks are updated completely -- actually only core
cookbook needed a major update since we had a lot of new parameters for
dns, transport layers, etc...
All of this confusion - starting with the fundamental difference
between K and SR, which nobody *I* know in the user community yet
understands in any level of substance or detail
Kamailio is the same -- will be a new major release of the sip server
everybody know so far -- new features in core plus some new modules,
either new development (memcache) or imported from ser (iptrtproxy). To
update from kamailio 1.5 to 3.0 you will need, as usual, some db
structure updates (not much afaik - lcr module, maybe cr) and some
updates to config file syntax (minimal as well for most of usage cases).
Your questions can be rephrased as "what is the difference between linux
and debian?". Debian is just a particular packaging of available linux
applications. In similar way, Kamailio, is SR core plus selection of SR
modules. Like in linux, where are application that overlap in
functionality, and one is preferred over the others (e.g., MTA), in SR
there are modules that overlap (e.g., auth) using a different
concept/database structure and one is preferred to the other.
I also encounter the widespread perception from my
customers that a
lot of time has been spent on "fun"
I would have liked some fun, but
there wasn't, not for me, very
interesting perception I would say, maybe you can point me such cases.
It was quite heavy work. The goal of trying to preserve max
compatibility while not messing up a lot of code in core was achieved -
the core impact was kept minimal, therefore inheriting stability from
ser 2.0. Several modules took the load of extra features.
and "interesting" integration work, not on
developing features or
fixing bugs. I hope they're wrong.
What are the bugs staying unfixed? What are
missing features not
adopted? There was quite a lot of new development, including transport
layer such as sctp, asyncronous message processing (t_suspend/t_continue
which is functional), continuing with new modules (link provided in
previous email).
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
1:48 p.m.
New subject: [Kamailio-Users] [sr-dev] kamailio 3.0 - the time before freezing
Daniel-Constantin Mierla wrote:
That's good to know. Half the problem is that people who don't know
this scour all the documentation in an attempt to gain a holistic grasp
of what the changes are, whether or not there are any.
It's not my perception.
As I said, not my perception, so I personally cannot answer any of that.
I personally see a lot of new and interesting features and a fair bit
of stability.
--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Hello,
On 24.08.2009 14:14 Uhr, Alex Balashov wrote:
Yes, I will review it and make a list.
The sip-router.org documentation is already
excessively complicated
and difficult to understand for anyone who does not routinely work
with both the K and S code. At this point, the documentation, while
voluminous, is overwhelming and, in places, woefully incomplete,
can you point such places? while in other
places, I would say "exhaustively" (perhaps
"exhaustingly") complete.
From K point of view, same documentation is available, the core, pv and
transformations cookbooks are updated completely -- actually only core
cookbook needed a major update since we had a lot of new parameters for
dns, transport layers, etc... Your questions can be rephrased as "what is the
difference between linux
and debian?". Debian is just a particular packaging of available linux
applications. In similar way, Kamailio, is SR core plus selection of SR
modules. Like in linux, where are application that overlap in
functionality, and one is preferred over the others (e.g., MTA), in SR
there are modules that overlap (e.g., auth) using a different
concept/database structure and one is preferred to the other.
I already understood this. The question is - why would one be preferred
to the other, from a practical perspective? What are the substantive
differences?
I also
encounter the widespread perception from my customers that a
lot of time has been spent on "fun"
I would have liked some fun, but there wasn't, not for me, very
interesting perception I would say, maybe you can point me such cases.
It was quite heavy work. The goal of trying to preserve max
compatibility while not messing up a lot of code in core was achieved -
the core impact was kept minimal, therefore inheriting stability from
ser 2.0. Several modules took the load of extra features. and
"interesting" integration work, not on developing features or
fixing bugs. I hope they're wrong.
What are the bugs staying unfixed? What
are missing features not
adopted? There was quite a lot of new development, including transport
layer such as sctp, asyncronous message processing (t_suspend/t_continue
which is functional), continuing with new modules (link provided in
previous email).
1:54 p.m.
New subject: [Kamailio-Users] [sr-dev] kamailio 3.0 - the time before freezing
Daniel-Constantin Mierla writes:
Kamailio is the same -- will be a new major release of
the sip server
everybody know so far -- new features in core plus some new modules,
either new development (memcache) or imported from ser (iptrtproxy). To
update from kamailio 1.5 to 3.0 you will need, as usual, some db
structure updates (not much afaik - lcr module, maybe cr) and some
updates to config file syntax (minimal as well for most of usage
cases).
how about kamctl? i don't find it in sip-router source. i understand
that it is now replaced by serctl. if what you say in above would be
true, there would still be also kamctl that is an important part of k.
better if there would be just sip-router with srctl to control it.
-- juha
2:07 p.m.
New subject: [Kamailio-Users] [sr-dev] kamailio 3.0 - the time before freezing
On 24.08.2009 14:54 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
kamctl is in sip-router, check tools directory.
Kamailio is the same -- will be a new major
release of the sip server
everybody know so far -- new features in core plus some new modules,
either new development (memcache) or imported from ser (iptrtproxy). To
update from kamailio 1.5 to 3.0 you will need, as usual, some db
structure updates (not much afaik - lcr module, maybe cr) and some
updates to config file syntax (minimal as well for most of usage
cases).
how about kamctl? i don't find it in sip-router source. i understand
that it is now replaced by serctl. if what you say in above would be
true, there would still be also kamctl that is an important part of k.
better if there would be just sip-router with srctl to
control it.
You are more than welcome to implement the srctl, I am going to
contribute if I am able to and use it.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
2:14 p.m.
New subject: [Kamailio-Users] [sr-dev] kamailio 3.0 - the time before freezing
Daniel-Constantin Mierla writes:
kamctl is in sip-router, check tools directory.
ok, i looked at scripts dir where it used to be in k.
You are more than welcome to implement the srctl, I am
going to
contribute if I am able to and use it.
srctl sort of exists already, but is is called serctl.
-- juha
2:57 p.m.
New subject: [Kamailio-Users] [sr-dev] kamailio 3.0 - the time before freezing
On 24.08.2009 15:14 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
:-) -- ahh, yes, imo, srctl sort of exists already, but is called kamctl.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
kamctl is in sip-router, check tools directory.
ok, i looked at scripts dir where it used to be in k.
You are more than welcome to implement the srctl,
I am going to
contribute if I am able to and use it.
srctl sort of exists already, but is is called serctl.
3:05 p.m.
New subject: [Kamailio-Users] [sr-dev] kamailio 3.0 - the time before freezing
Daniel-Constantin Mierla writes:
:-) -- ahh, yes, imo, srctl sort of exists already,
but is called
kamctl.
are you saying that one can control s modules with kamctl? i know that
one can control both s and k modules with serctl (except for async
t_uac_dlg).
-- juha
3:34 p.m.
New subject: [Kamailio-Users] [sr-dev] kamailio 3.0 - the time before freezing
On 24.08.2009 16:05 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
i don't think serctl can add K users nor do other K management commands.
serctl (actually I refer to sercmd since I have no idea about serctl)
does RPC commands and since I added the mi_rpc command you can invoke a
MI command via RPC.
Never tried, but see:
http://sip-router.org/docbook/sip-router/branch/master/modules_s/ctl/ctl.ht…
kamctl implements that kind of communication proto.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
:-) -- ahh, yes, imo, srctl sort of exists
already, but is called
kamctl.
are you saying that one can control s modules with kamctl? i know that
one can control both s and k modules with serctl (except for async
t_uac_dlg).
12:49 p.m.
New subject: [Kamailio-Users] kamailio 3.0 - the time before freezing
2009/8/24 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Hello everybody,
during the last IRC devel meeting, we pinned end of summer to be the time to
enter testing phase for the new major release - codenamed kamailio 3.0.
There was quite a lot of brand new features, considering that most of devel
effort was directed to integration. A try to collect new items is available
at:
http://sip-router.org/wiki/features/new-in-devel
Hi, I read:
-----------------
script mode can be switched between ser compatible, kamailio
compatible and max compatibility (compatible with both as much as
possible), using
#!SER
#!KAMAILIO
#!OPENSER
#!ALL
#!MAXCOMPAT
-----------------
Is it a good approach? why not make it strict for a definitive syntax?
(this will occur soon or late and when it occurs it will break config
files with all these syntaxs).
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
12:58 p.m.
New subject: [Kamailio-Users] kamailio 3.0 - the time before freezing
Hello,
On 24.08.2009 13:49 Uhr, Iñaki Baz Castillo wrote:
2009/8/24 Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
this mechanism was introduced in the early phase of integration to
provide support for eventual major conflicts. AFAIK we haven't run into
a deadlock requiring selecting a specific mode. The Kamailio PVs
overlapping in naming with SER AVPs was the most important case, solved
by looking up first PV and if not found assume is avp using SER syntax.
Andrei can correct me if I overlooked something.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
Hello everybody,
during the last IRC devel meeting, we pinned end of summer to be the time to
enter testing phase for the new major release - codenamed kamailio 3.0.
There was quite a lot of brand new features, considering that most of devel
effort was directed to integration. A try to collect new items is available
at:
http://sip-router.org/wiki/features/new-in-devel
Hi, I read:
-----------------
script mode can be switched between ser compatible, kamailio
compatible and max compatibility (compatible with both as much as
possible), using
#!SER
#!KAMAILIO
#!OPENSER
#!ALL
#!MAXCOMPAT
-----------------
Is it a good approach? why not make it strict for a definitive syntax?
(this will occur soon or late and when it occurs it will break config
files with all these syntaxs).
5365
days inactive
5366
days old
36 comments
7 participants
participants (7)
-
Alex Balashov -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
jh＠tutpro.com -
Klaus Darilion -
Martin Hoffmann -
MÉSZÁROS Mihály