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 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
Hello,
On 24.08.2009 13:47 Uhr, Juha Heinanen wrote:
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.
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
On 24.08.2009 13:52 Uhr, Daniel-Constantin Mierla wrote:
Hello,
On 24.08.2009 13:47 Uhr, Juha Heinanen wrote:
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.
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.
^^^ is not very ...
Daniel
You can still use one interface though - MI is fully available and does (pseudo) async xmlrpc commands.
Cheers, Daniel
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
On 24.08.2009 13:58 Uhr, Juha Heinanen wrote:
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).
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.
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
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.
2009/8/24 Alex Balashov abalashov@evaristesys.com:
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 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 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
Martin Hoffmann wrote:
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.
Perhaps. But, building in a mandatory premise of (nontrivial) future change as part of "eventually, the difference will go away" is not attractive.
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
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 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.
On 24.08.2009 15:08 Uhr, Alex Balashov wrote:
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
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.
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 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
On 24.08.2009 16:29 Uhr, Alex Balashov wrote:
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.
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
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 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?
On 24.08.2009 16:47 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.
Well, maybe not the above-mentioned modules, but certainly some.
definitely, yes!
Cheers, Daniel
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?
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.
On 24.08.2009 15:57 Uhr, Iñaki Baz Castillo wrote:
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.
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
Iñaki Baz Castillo schrieb:
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?
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
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.
Klaus Darilion wrote:
Iñaki Baz Castillo schrieb:
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?
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.
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
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.
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.
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
MÉSZÁROS Mihály schrieb:
Klaus Darilion wrote:
Iñaki Baz Castillo schrieb:
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?
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.
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.
Yes, that's true. That's why Daniel said he tries to merge the sl modules
regards klaus
El Lunes, 24 de Agosto de 2009, Daniel-Constantin Mierla escribió:
. 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.
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.
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 :)
On 25.08.2009 2:01 Uhr, Iñaki Baz Castillo wrote:
El Lunes, 24 de Agosto de 2009, Daniel-Constantin Mierla escribió:
. 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.
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.
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?
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.
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
2009/8/25 Daniel-Constantin Mierla miconda@gmail.com:
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.
Great, now 100% understood :)
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 wrote:
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?
Yes, I will review it and make a list.
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...
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.
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.
It's not my perception.
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).
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.
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
On 24.08.2009 14:54 Uhr, Juha Heinanen wrote:
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.
kamctl is in sip-router, check tools directory.
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 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
On 24.08.2009 15:14 Uhr, Juha Heinanen wrote:
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.
:-) -- ahh, yes, imo, srctl sort of exists already, but is called kamctl.
Cheers, Daniel
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
On 24.08.2009 16:05 Uhr, Juha Heinanen wrote:
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).
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.htm...
kamctl implements that kind of communication proto.
Cheers, Daniel
2009/8/24 Daniel-Constantin Mierla miconda@gmail.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:
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).
Hello,
On 24.08.2009 13:49 Uhr, Iñaki Baz Castillo wrote:
2009/8/24 Daniel-Constantin Mierla miconda@gmail.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:
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).
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
-
Alex Balashov -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
jh＠tutpro.com -
Klaus Darilion -
Martin Hoffmann -
MÉSZÁROS Mihály