Module: sip-router Branch: master Commit: 5d1a75a61b349690125db87c1e48b3de580613e6 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=5d1a75a6...
Author: Juha Heinanen jh@tutpro.com Committer: Juha Heinanen jh@tutpro.com Date: Wed Jun 24 15:44:10 2009 +0300
* Core, etc, documentation: renamed ser to sip-router
* Renamed ser to sip-router in Makefile, etc files and some core files. * Renamed some etc files from ser based name to sip-router based name.
---
INSTALL | 214 +++++++++++++----------- Makefile | 106 ++++++------ Makefile.defs | 2 +- config.h | 2 +- etc/dbtext.cfg | 6 +- etc/{dictionary.ser => dictionary.sip-router} | 0 etc/nathelper.cfg | 24 ++-- etc/rules.m4 | 2 +- etc/{ser-basic.cfg => sip-router-basic.cfg} | 14 +- etc/{ser-oob.cfg => sip-router-oob.cfg} | 26 ++-- etc/{ser.cfg => sip-router.cfg} | 0 etc/{ser.cfg.m4 => sip-router.cfg.m4} | 46 +++--- etc/sr | 34 ++-- rad_dict.h | 2 +- ser.8 | 48 +++--- 15 files changed, 272 insertions(+), 254 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=5d1a...
On Jun 24, 2009 at 15:49, Juha Heinanen jh@tutpro.com wrote:
Juha Heinanen writes:
- Core, etc, documentation: renamed ser to sip-router
this was just a start. i'm sure there is still lot to do. do we have any deadline on when first sip-router release (or its beta) should be available?
Not as far as I know. The only deadline is that the next kamailio version based on sip-router (3.0?) should be ready around September (please correct me if I'm wrong).
We still have the problem that we haven't decided yet on a short-name. (while the project is called sip-router, we haven't decided on the short binary name). Unfortunately this is proving to be very difficult since there are a lot of very different opinions (we tried once before and we gave up after 2 days because there was no agreement in sight).
Andrei
Andrei Pelinescu-Onciul writes:
We still have the problem that we haven't decided yet on a short-name. (while the project is called sip-router, we haven't decided on the short binary name). Unfortunately this is proving to be very difficult since there are a lot of very different opinions (we tried once before and we gave up after 2 days because there was no agreement in sight).
my proposal is to call binary/config file sip-router/sip-router.cfg. sr would be too short. tools, like ctl, could be prefixed with sr.
-- juha
On Wednesday 24 June 2009 14:49:37 Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
We still have the problem that we haven't decided yet on a short-name. (while the project is called sip-router, we haven't decided on the short binary name). Unfortunately this is proving to be very difficult since there are a lot of very different opinions (we tried once before and we gave up after 2 days because there was no agreement in sight).
my proposal is to call binary/config file sip-router/sip-router.cfg. sr would be too short. tools, like ctl, could be prefixed with sr.
I like this proposal, look simple and clear.
On 06/24/2009 04:01 PM, Raúl Alexis Betancor Santana wrote:
On Wednesday 24 June 2009 14:49:37 Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
We still have the problem that we haven't decided yet on a short-name. (while the project is called sip-router, we haven't decided on the short binary name). Unfortunately this is proving to be very difficult since there are a lot of very different opinions (we tried once before and we gave up after 2 days because there was no agreement in sight).
my proposal is to call binary/config file sip-router/sip-router.cfg. sr would be too short. tools, like ctl, could be prefixed with sr.
I like this proposal, look simple and clear.
This is very bad from project identity point of view. I have been few weeks ago at a conference in Germany and telling people that I present sip router, everyone asked "which one?" It really looks ridiculous to say something like " I manufacture a car named 'car' " (or "I develop a sip router name sip router").
Therefore, if matters, there should be some other identifier for the project to make it easy to refer to others.
Cheers, Daniel
Daniel-Constantin Mierla writes:
Therefore, if matters, there should be some other identifier for the project to make it easy to refer to others.
you propose inventing a new name? i would not like to repeat kamailio ordeal.
anyone can call their binaries whatever they like. you just define MAIN_NAME. in my opinion, the default in the repository can be sip-router.
-- juha
On 06/24/2009 04:30 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Therefore, if matters, there should be some other identifier for the project to make it easy to refer to others.
you propose inventing a new name? i would not like to repeat kamailio ordeal.
anyone can call their binaries whatever they like. you just define MAIN_NAME. in my opinion, the default in the repository can be sip-router.
I would prefer to stick and keep the name as "sip express router" rather than dry "sip router" -- it makes an unique identifier for the project.
Unlike you, I personally see the other way around. Those working with the public project and spending resources in developing and promoting the project, not a private platform based on the project, need something to use. While any private distro can use a different name and binaries by MAIN_NAME, the default public one should suggest without confusion this particular project.
Daniel
Daniel-Constantin Mierla writes:
I would prefer to stick and keep the name as "sip express router" rather than dry "sip router" -- it makes an unique identifier for the project.
"sip express router" gives message that the project is just a new version of ser and does not recognize the work done by lot of people on openser and kamailio. if you want a unique identifier, invent a new one.
-- juha
On 06/24/2009 04:50 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I would prefer to stick and keep the name as "sip express router" rather than dry "sip router" -- it makes an unique identifier for the project.
"sip express router" gives message that the project is just a new version of ser and does not recognize the work done by lot of people on openser and kamailio. if you want a unique identifier, invent a new one.
I am not eager to find a new one, there is no pressure to release entire project from sip-router.org git repository under new identity, so I was happy with using ser so far and no others complained. SER can be from "sip extensible router" or something else in the middle starting with "E".
Regarding the relevance of contributions based on project name, you have a lot if work done in ser as well, from before the openser fork. Many others have as well and sip router as name does not suggest/recognize better the work of people from different project.
While sip router is ok to preserve in a way or other in the name, there is need for something like a middle name so one can quickly match this project.
When talking with people about sip router, the first project coming in their mind is ser, then is kamailio (openser) (and maybe others), explaining the existence of a third one named exactly "sip router" is kind of awkward and very confusing.
Daniel
On Jun 24, 2009 at 17:14, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 06/24/2009 04:50 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I would prefer to stick and keep the name as "sip express router"
rather > than dry "sip router" -- it makes an unique identifier for the
project.
"sip express router" gives message that the project is just a new version of ser and does not recognize the work done by lot of people on openser and kamailio. if you want a unique identifier, invent a new one.
I am not eager to find a new one, there is no pressure to release entire project from sip-router.org git repository under new identity, so I was happy with using ser so far and no others complained. SER can be from "sip extensible router" or something else in the middle starting with "E".
Regarding the relevance of contributions based on project name, you have a lot if work done in ser as well, from before the openser fork. Many others have as well and sip router as name does not suggest/recognize better the work of people from different project.
While sip router is ok to preserve in a way or other in the name, there is need for something like a middle name so one can quickly match this project.
When talking with people about sip router, the first project coming in their mind is ser, then is kamailio (openser) (and maybe others), explaining the existence of a third one named exactly "sip router" is kind of awkward and very confusing.
Unfortunately this discussion seems to de-generate in a long thread and honestly I don't think it would be useful. The only result I see is time lost, time that could go into development, testing or docs. The problem is that for something as simple as a short-name everybody has a very strong opinion and there are very few objective criteria to filter through the proposals. I think the only constructive way to go forward is to find a commonly accepted procedure for choosing a name (maybe keep a list of proposals, that should satisfy a few criterias and then at some point have a vote, either over the net or during a public meeting). We could also delay this to some undefined future point :-)
For the record I do partially agree with Daniel. I do not want a new "trademark" for the project, but I think we need a short name, something only a few letter long. sr would be great, but unfortunately is too common. ser would work for me too (I guess this is no surprise), but I understand that some people might not want it.
Andrei
On 06/24/2009 05:42 PM, Andrei Pelinescu-Onciul wrote:
On Jun 24, 2009 at 17:14, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 06/24/2009 04:50 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I would prefer to stick and keep the name as "sip express router"
rather > than dry "sip router" -- it makes an unique identifier for the
project.
"sip express router" gives message that the project is just a new version of ser and does not recognize the work done by lot of people on openser and kamailio. if you want a unique identifier, invent a new one.
I am not eager to find a new one, there is no pressure to release entire project from sip-router.org git repository under new identity, so I was happy with using ser so far and no others complained. SER can be from "sip extensible router" or something else in the middle starting with "E".
Regarding the relevance of contributions based on project name, you have a lot if work done in ser as well, from before the openser fork. Many others have as well and sip router as name does not suggest/recognize better the work of people from different project.
While sip router is ok to preserve in a way or other in the name, there is need for something like a middle name so one can quickly match this project.
When talking with people about sip router, the first project coming in their mind is ser, then is kamailio (openser) (and maybe others), explaining the existence of a third one named exactly "sip router" is kind of awkward and very confusing.
Unfortunately this discussion seems to de-generate in a long thread and honestly I don't think it would be useful.
I am of same opinion, my focus was to get things integrated, but the changes started to happen already, being committed without a proper discussion here -- not something good from collaboration point of view.
So now all my testing environment is broken, scripts, paths and so on and maybe has to be changed again soon. Probably such actions needs more than one hour decision and quickly commit because one just liked more a new name than existing one.
Daniel
The only result I see is time lost, time that could go into development, testing or docs. The problem is that for something as simple as a short-name everybody has a very strong opinion and there are very few objective criteria to filter through the proposals. I think the only constructive way to go forward is to find a commonly accepted procedure for choosing a name (maybe keep a list of proposals, that should satisfy a few criterias and then at some point have a vote, either over the net or during a public meeting). We could also delay this to some undefined future point :-)
For the record I do partially agree with Daniel. I do not want a new "trademark" for the project, but I think we need a short name, something only a few letter long. sr would be great, but unfortunately is too common. ser would work for me too (I guess this is no surprise), but I understand that some people might not want it.
Andrei
Daniel-Constantin Mierla writes:
I am of same opinion, my focus was to get things integrated, but the changes started to happen already, being committed without a proper discussion here -- not something good from collaboration point of view.
i asked about renaming of ser.cfg on the list and jan replied that it is ok. if project does not like its own name to be used in default configuration then please go ahead and undo the changes. i'm not going to get involved with anything that has 'ser' or 'kamailio' hardwired in the default config or makefiles.
-- juha
On 06/24/2009 08:38 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I am of same opinion, my focus was to get things integrated, but the changes started to happen already, being committed without a proper discussion here -- not something good from collaboration point of view.
i asked about renaming of ser.cfg on the list and jan replied that it is ok.
so probably this means the entire project, or? IIRC I replied quite quickly questioning such decision and suggesting to keep ser for now.
if project does not like its own name to be used in default configuration then please go ahead and undo the changes. i'm not going to get involved with anything that has 'ser' or 'kamailio' hardwired in the default config or makefiles.
I think such attitude is not going anywhere. What is missing now is that I would say "I am not going to be involved in anything having sip-router hardwired". Sad to see this.
The problem that is risen now is the type of actions taken, while we agreed that any changes to common framework have to be properly discussed on devel list, radical changes were done without this rule. I know that this particular issue is a matter of tastes and personal preferences, that's why needs careful handling.
It might be easier and nicer for you now, but you just broke about 10 testing instances I have.
Jumping and changing quickly is not a solution, coming back asking others to do update to something else if they do not like the current just committed is more like chaos. In this way, during one day we can get hell-out of many names.
Daniel
Daniel-Constantin Mierla writes:
i asked about renaming of ser.cfg on the list and jan replied that it is ok.
so probably this means the entire project, or? IIRC I replied quite quickly questioning such decision and suggesting to keep ser for now.
i don't know about entire project. i just changed ser.cfg to sip-router.cfg and what else it implied.
I think such attitude is not going anywhere. What is missing now is that I would say "I am not going to be involved in anything having sip-router hardwired". Sad to see this.
if you want to make it easy to use your own name, change Makefile system so that no file names are hardwired. they simply my changing MAIN_NAME you can get every file (config files, man pages, etc.) named whatever way you like.
The problem that is risen now is the type of actions taken, while we agreed that any changes to common framework have to be properly discussed on devel list, radical changes were done without this rule. I know that this particular issue is a matter of tastes and personal preferences, that's why needs careful handling.
i didn't rename any k files or their contents. i only edited and renamed ser to sip-router. i thought that jan as member or ser project could give such an ok.
-- juha
On Jun 24, 2009 at 22:08, Juha Heinanen jh@tutpro.com wrote:
Daniel-Constantin Mierla writes:
i asked about renaming of ser.cfg on the list and jan replied that it is ok.
so probably this means the entire project, or? IIRC I replied quite quickly questioning such decision and suggesting to keep ser for now.
i don't know about entire project. i just changed ser.cfg to sip-router.cfg and what else it implied.
You single-handledly changed everything, including the binary name. I don't care so much how a config file is called, but so far there is no decision for the binary name so it should not be changed (I'll revert it).
Even the config changes went a little bit too far, breaking all the scripts (but at least you're taking care of that), for no good reason.
I think such attitude is not going anywhere. What is missing now is that I would say "I am not going to be involved in anything having sip-router hardwired". Sad to see this.
if you want to make it easy to use your own name, change Makefile system so that no file names are hardwired. they simply my changing MAIN_NAME you can get every file (config files, man pages, etc.) named whatever way you like.
I think you should have done that.
The problem that is risen now is the type of actions taken, while we agreed that any changes to common framework have to be properly discussed on devel list, radical changes were done without this rule. I know that this particular issue is a matter of tastes and personal preferences, that's why needs careful handling.
i didn't rename any k files or their contents. i only edited and renamed ser to sip-router. i thought that jan as member or ser project could give such an ok.
Andrei
Andrei Pelinescu-Onciul writes:
You single-handledly changed everything, including the binary name. I don't care so much how a config file is called, but so far there is no decision for the binary name so it should not be changed (I'll revert it).
fine, make it "undecided".
-- juha
Juha Heinanen writes:
fine, make it "undecided".
i would like to add that i'm coming from kamailio project and using binary name "ser" in sip-router project is not acceptable to me. there was never a decision on that. it just happened. "sip-router" is a neutral choice until the community votes on the final name.
-- juha
On 06/24/2009 09:39 PM, Juha Heinanen wrote:
Juha Heinanen writes:
fine, make it "undecided".
i would like to add that i'm coming from kamailio project and using binary name "ser" in sip-router project is not acceptable to me.
... coming from same direction and for me is not acceptable that strong personal opinions/interests drive decisions regarding the core framework and public project without proper discussion.
I and probably others have completely different names when deploying the application in particular cases, but that is something I keep it inside my company as patches or cloned repository. Sure would be easy if I would change it on the public project so the others will do it, not me, but we are a group of people that invest a lot of their private resources, so we should act democratically.
Now happened with the name, but in the future one can think of something else, turning in a chaotic evolution, so we rather (and better) have it clear from this point of time, otherwise makes no sense to continue.
Daniel
there was never a decision on that. it just happened. "sip-router" is a neutral choice until the community votes on the final name.
Daniel-Constantin Mierla writes:
Now happened with the name, but in the future one can think of something else, turning in a chaotic evolution, so we rather (and better) have it clear from this point of time, otherwise makes no sense to continue.
daniel,
rather than complaining, work on the goal that allows you to change the binary name and name used in the docs and scripts by changing MAIN_NAME in Makefile.defs.
-- juha
On 06/24/2009 10:22 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Now happened with the name, but in the future one can think of something else, turning in a chaotic evolution, so we rather (and better) have it clear from this point of time, otherwise makes no sense to continue.
daniel,
rather than complaining, work on the goal that allows you to change the binary name and name used in the docs and scripts by changing MAIN_NAME in Makefile.defs.
well, I haven't seen such attitude and commitment when was about updating the modules to compile with sip router or porting k tm or core features. But suddenly because one decides alone to do some change, others should work to fix it now. No, thanks. My list of volunteer work is full of other more useful things at this time. Probably I am not the best one to ask for more free contribution on useless aspects, besides the fact makefile is not a strong point of me.
I believe I am not sitting aside at all and complaining to others to do something for me. It got to this point because of how the rename action was undertaken. Be sure I would have had same reaction if something else would have been changed in the core affecting the project.
Daniel
daniel,
i just checked and my debian build (the one that i posted to the list) went thought without any errors after the ser -> sip-router change.
-- juha
Juha Heinanen escreveu:
daniel,
i just checked and my debian build (the one that i posted to the list) went thought without any errors after the ser -> sip-router change.
-- juha
Just adding report that compiled without error on OpenSUSE 11.1
To preserve directory structure adopted by OpenSUSE, compilation command was: make prefix=/ LOCALBASE=/ man_prefix=/usr install
Edson.
Hello,
On 06/24/2009 09:34 PM, Edson - Lists wrote:
Juha Heinanen escreveu:
daniel,
i just checked and my debian build (the one that i posted to the list) went thought without any errors after the ser -> sip-router change.
-- juha
Just adding report that compiled without error on OpenSUSE 11.1
To preserve directory structure adopted by OpenSUSE, compilation command was: make prefix=/ LOCALBASE=/ man_prefix=/usr install
I am not using debs or rpms. I use the source code.
So now everything related to installation changed in not time, like binaries, paths, cfg files -- lot of things I built to make the migration and integration going faster and better became worthless.
I have nothing against building the make framework where changing name does it smoothly across all source code, config file, installation paths. But changing the defaults really affects lot of existing stuff. So at least should be announced, once agreed at some point.
Daniel
Daniel-Constantin Mierla escreveu:
Hello,
On 06/24/2009 09:34 PM, Edson - Lists wrote:
Juha Heinanen escreveu:
daniel,
i just checked and my debian build (the one that i posted to the list) went thought without any errors after the ser -> sip-router change.
-- juha
Just adding report that compiled without error on OpenSUSE 11.1
To preserve directory structure adopted by OpenSUSE, compilation command was: make prefix=/ LOCALBASE=/ man_prefix=/usr install
I am not using debs or rpms. I use the source code.
So now everything related to installation changed in not time, like binaries, paths, cfg files -- lot of things I built to make the migration and integration going faster and better became worthless.
I have nothing against building the make framework where changing name does it smoothly across all source code, config file, installation paths. But changing the defaults really affects lot of existing stuff. So at least should be announced, once agreed at some point.
Daniel
Sorry, Daniel...
Just that I think that You misunderstand my e-mail.... I just reported that compilation went ok and included the command used to accomplish it. I also use source code.
The default name discussion is a complete another story from my report.
Edson.
On Wed, Jun 24, 2009 at 5:42 PM, Andrei Pelinescu-Onciulandrei@iptel.org wrote:
I think the only constructive way to go forward is to find a commonly accepted procedure for choosing a name (maybe keep a list of proposals, that should satisfy a few criterias and then at some point have a vote, either over the net or during a public meeting).
I believe this would be the most reasonable way to move forward.
El Miércoles, 24 de Junio de 2009, Victor Pascual Ávila escribió:
On Wed, Jun 24, 2009 at 5:42 PM, Andrei
Pelinescu-Onciulandrei@iptel.org wrote:
I think the only constructive way to go forward is to find a commonly accepted procedure for choosing a name (maybe keep a list of proposals, that should satisfy a few criterias and then at some point have a vote, either over the net or during a public meeting).
I believe this would be the most reasonable way to move forward.
The question are:
- Does SIP-Router need *right now* the final official name in order to rename binaries, scripts and config files with it?
- If it's too soon for that, does SIP-Router need *right now* an unique identifier (something more "unique" than sip-router and less ambiguous than "ser") for internal user?
I propose a different solution:
A common user or person which doesn't know about the project's origin will not inspect the sources to find the binary and realize of the software "name". So the internal identifier could remain as it's now ("ser") in order to make easy the continuous development. But in parallel a new official name could be choosen ("Hyper-SIP-Proxy- MegaPRO") and that would be the name announced in public meeting, web page and so. Then, when the first release of Hyper-SIP-Proxy-MegaPRO arrives, all the binaries, scripts and config files would be renamed to "hyper-sip-proxy- megapro" (we avoid changing two times the internal identifier during the long development process).
What doesn't make sense (IMHO) is mantaining "SIP-Router" in the official page for long time, and when some people already knows it then releasing a new official name (this would create confusion).
Just my 3 cents.
On Wednesday 24 June 2009 15:22:50 Daniel-Constantin Mierla wrote:
On 06/24/2009 04:01 PM, Raúl Alexis Betancor Santana wrote:
On Wednesday 24 June 2009 14:49:37 Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
We still have the problem that we haven't decided yet on a short-name. (while the project is called sip-router, we haven't decided on the short binary name). Unfortunately this is proving to be very difficult since there are a lot of very different opinions (we tried once before and we gave up after 2 days because there was no agreement in sight).
my proposal is to call binary/config file sip-router/sip-router.cfg. sr would be too short. tools, like ctl, could be prefixed with sr.
I like this proposal, look simple and clear.
This is very bad from project identity point of view. I have been few weeks ago at a conference in Germany and telling people that I present sip router, everyone asked "which one?" It really looks ridiculous to say something like " I manufacture a car named 'car' " (or "I develop a sip router name sip router").
Therefore, if matters, there should be some other identifier for the project to make it easy to refer to others.
Cheers, Daniel
Hi Daniel, I was just speaking about the binary/config name, not the project name.
I supposed that if sip-router is been used as project name from the beginning, chaning it now could be dangerous ... another project name change in less than a year ? ... buff I don't see it
On 06/24/2009 04:39 PM, Raúl Alexis Betancor Santana wrote:
On Wednesday 24 June 2009 15:22:50 Daniel-Constantin Mierla wrote:
On 06/24/2009 04:01 PM, Raúl Alexis Betancor Santana wrote:
On Wednesday 24 June 2009 14:49:37 Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
We still have the problem that we haven't decided yet on a short-name. (while the project is called sip-router, we haven't decided on the short binary name). Unfortunately this is proving to be very difficult since there are a lot of very different opinions (we tried once before and we gave up after 2 days because there was no agreement in sight).
my proposal is to call binary/config file sip-router/sip-router.cfg. sr would be too short. tools, like ctl, could be prefixed with sr.
I like this proposal, look simple and clear.
This is very bad from project identity point of view. I have been few weeks ago at a conference in Germany and telling people that I present sip router, everyone asked "which one?" It really looks ridiculous to say something like " I manufacture a car named 'car' " (or "I develop a sip router name sip router").
Therefore, if matters, there should be some other identifier for the project to make it easy to refer to others.
Cheers, Daniel
Hi Daniel, I was just speaking about the binary/config name, not the project name.
I supposed that if sip-router is been used as project name from the beginning, chaning it now could be dangerous ... another project name change in less than a year ? ... buff I don't see it
I think you do a confusion at this particular time. Kamailio project goes on because there are overlapping modules from ser that won't be integrated. I don't think that people would be happy to drop modules from a side or another (e.g., like auth modules that are present in both modules_k and modules_s).
We are talking about this particular project hosted by sip-router.org which had no release so far, but needs an identity. Next version of kamailio will still be named kamailio and include the modules inherited from kamailio, probably including some modules from ser as well.
As it seems a pure ser release is not planned yet, we can stick with this name for a while, because it is there and it is unique. In kamailio, we do releases every 6 months, therefore September is just about the time.
Cheers, Daniel
Daniel-Constantin Mierla writes:
We are talking about this particular project hosted by sip-router.org which had no release so far, but needs an identity. Next version of kamailio will still be named kamailio and include the modules inherited from kamailio, probably including some modules from ser as well.
this is news to me. i'm pretty sure that there was a plan that 1.5 will be the last version of kamailio, but haven't checked mail archives.
if that will not be the case, it would have made no sense to start putting all kinds of migration documentation there. we should have simply kept on using the k site and update the docs there.
if you plan to keep on using name kamailio, then you can do whatever name changes you want there when you package next version of kamailio. i'm not going to be any part of that, but keep on using and contributing only to sip router project.
regarding modules, everyone can pick from modules subdirs whatever modules they like to use. over time it would make sense to try to unite k and ser modules when feasible in order to save maintenance resources.
-- juha
On Jun 24, 2009 at 18:06, Juha Heinanen jh@tutpro.com wrote:
Daniel-Constantin Mierla writes:
We are talking about this particular project hosted by sip-router.org which had no release so far, but needs an identity. Next version of kamailio will still be named kamailio and include the modules inherited from kamailio, probably including some modules from ser as well.
this is news to me. i'm pretty sure that there was a plan that 1.5 will be the last version of kamailio, but haven't checked mail archives.
I haven't checked them either but AFAIK 1.5 was supposed to be the last version _not_ based on sip-router.
From a technical point of view is just not possible to merge everything
till September. We have a lot of modules we have not even began to discuss, we have completely different DB schemes a.s.o.
So while the goal is to completely merge kamailio and ser under sip-router (with perhaps some duplicate modules), it will take a while (hopefully 1 extra release cycle will be enough).
if that will not be the case, it would have made no sense to start putting all kinds of migration documentation there. we should have simply kept on using the k site and update the docs there.
if you plan to keep on using name kamailio, then you can do whatever name changes you want there when you package next version of kamailio. i'm not going to be any part of that, but keep on using and contributing only to sip router project.
regarding modules, everyone can pick from modules subdirs whatever modules they like to use. over time it would make sense to try to unite k and ser modules when feasible in order to save maintenance resources.
Yes, there is a lot of work ahead of us (discuss on a module by module basis, decide on the DB schema, new module interface a.s.o.) but we'll slowly get there. So far at least from my point of view the priority is to be able to build a stable kamailio and ser distributions out of sip-router.
Andrei
On 06/24/2009 05:06 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
We are talking about this particular project hosted by sip-router.org which had no release so far, but needs an identity. Next version of kamailio will still be named kamailio and include the modules inherited from kamailio, probably including some modules from ser as well.
this is news to me. i'm pretty sure that there was a plan that 1.5 will be the last version of kamailio, but haven't checked mail archives.
if that will not be the case, it would have made no sense to start putting all kinds of migration documentation there. we should have simply kept on using the k site and update the docs there.
if you plan to keep on using name kamailio, then you can do whatever name changes you want there when you package next version of kamailio. i'm not going to be any part of that, but keep on using and contributing only to sip router project.
regarding modules, everyone can pick from modules subdirs whatever modules they like to use. over time it would make sense to try to unite k and ser modules when feasible in order to save maintenance resources.
yes, this is a long term goal. But that cannot be achieved now, so we have overlapping modules, overlapping tools, overlapping table names but different structure. The development and contributions are and will be done only to sip-router.org repository.
Complete module integration will take some time, cannot be done up to autumn and some are very delicate as people have tools relaying on current db structure of each project -- just for example, kamctl cannot handle ser db, serctl cannot handle kamailio db. Of course you can mix modules from both project, because you have the insights, but for a public release it will be a nightmare from support point of view.
So, to conclude, I am talking about public releases, not something (us as developers or very familiar users) build internally and use in our products/solutions. So when new users come, we can give them straight and clear answers.
Cheers, Daniel
El Miércoles, 24 de Junio de 2009, Daniel-Constantin Mierla escribió:
On 06/24/2009 04:01 PM, Raúl Alexis Betancor Santana wrote:
On Wednesday 24 June 2009 14:49:37 Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
We still have the problem that we haven't decided yet on a short-name. (while the project is called sip-router, we haven't decided on the short binary name). Unfortunately this is proving to be very difficult since there are a lot of very different opinions (we tried once before and we gave up after 2 days because there was no agreement in sight).
my proposal is to call binary/config file sip-router/sip-router.cfg. sr would be too short. tools, like ctl, could be prefixed with sr.
I like this proposal, look simple and clear.
This is very bad from project identity point of view. I have been few weeks ago at a conference in Germany and telling people that I present sip router, everyone asked "which one?" It really looks ridiculous to say something like " I manufacture a car named 'car' " (or "I develop a sip router name sip router").
Therefore, if matters, there should be some other identifier for the project to make it easy to refer to others.
Ops, I always really though that SIP-Router was the final name ¿? If not, when will it be decided?
On 06/24/2009 10:31 PM, Iñaki Baz Castillo wrote:
El Miércoles, 24 de Junio de 2009, Daniel-Constantin Mierla escribió:
On 06/24/2009 04:01 PM, Raúl Alexis Betancor Santana wrote:
On Wednesday 24 June 2009 14:49:37 Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
We still have the problem that we haven't decided yet on a short-name. (while the project is called sip-router, we haven't decided on the short binary name). Unfortunately this is proving to be very difficult since there are a lot of very different opinions (we tried once before and we gave up after 2 days because there was no agreement in sight).
my proposal is to call binary/config file sip-router/sip-router.cfg. sr would be too short. tools, like ctl, could be prefixed with sr.
I like this proposal, look simple and clear.
This is very bad from project identity point of view. I have been few weeks ago at a conference in Germany and telling people that I present sip router, everyone asked "which one?" It really looks ridiculous to say something like " I manufacture a car named 'car' " (or "I develop a sip router name sip router").
Therefore, if matters, there should be some other identifier for the project to make it easy to refer to others.
Ops, I always really though that SIP-Router was the final name ¿? If not, when will it be decided?
see the minutes after the Karlsruhe meeting: http://lists.sip-router.org/pipermail/sr-dev/2008-November/000051.html
The short name was taken in consideration at that time and mentioned as to-do, therefore a latter decision. sip-router started as project to create the common core and tm for k and ser, but not as stand-alone application name.
Daniel
El Miércoles, 24 de Junio de 2009, Raúl Alexis Betancor Santana escribió:
On Wednesday 24 June 2009 14:49:37 Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
We still have the problem that we haven't decided yet on a short-name. (while the project is called sip-router, we haven't decided on the short binary name). Unfortunately this is proving to be very difficult since there are a lot of very different opinions (we tried once before and we gave up after 2 days because there was no agreement in sight).
my proposal is to call binary/config file sip-router/sip-router.cfg. sr would be too short. tools, like ctl, could be prefixed with sr.
I like this proposal, look simple and clear.
Me too. It's the expected one.
Hi, Juha...
Just downloaded a clean source and try a compilation.... At the end I got:
# TLS configuration touch //etc/sip-router//tls.cfg install -m 644 modules/tls/tls.cfg //etc/sip-router/ modules/tls/sip-router_cert.sh -d //etc/sip-router/ make: modules/tls/sip-router_cert.sh: Command not found make: *** [install-cfg] Error 127
and on the directory the file stills is named: ser_cert.sh
Edson.
Juha Heinanen escreveu:
Module: sip-router Branch: master Commit: 5d1a75a61b349690125db87c1e48b3de580613e6 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=5d1a75a6...
Author: Juha Heinanen jh@tutpro.com Committer: Juha Heinanen jh@tutpro.com Date: Wed Jun 24 15:44:10 2009 +0300
Core, etc, documentation: renamed ser to sip-router
Renamed ser to sip-router in Makefile, etc files and some core files.
Renamed some etc files from ser based name to sip-router based name.
INSTALL | 214 +++++++++++++----------- Makefile | 106 ++++++------ Makefile.defs | 2 +- config.h | 2 +- etc/dbtext.cfg | 6 +- etc/{dictionary.ser => dictionary.sip-router} | 0 etc/nathelper.cfg | 24 ++-- etc/rules.m4 | 2 +- etc/{ser-basic.cfg => sip-router-basic.cfg} | 14 +- etc/{ser-oob.cfg => sip-router-oob.cfg} | 26 ++-- etc/{ser.cfg => sip-router.cfg} | 0 etc/{ser.cfg.m4 => sip-router.cfg.m4} | 46 +++--- etc/sr | 34 ++-- rad_dict.h | 2 +- ser.8 | 48 +++--- 15 files changed, 272 insertions(+), 254 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=5d1a...
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Seems that it has other problems, since in /etc I found two files that shouldn't be there : Kamailio-151:~/sr/sip-router # l /etc/sip-router* -rw-r--r-- 1 root root 44865 Jun 10 16:11 /etc/sip-routerser-advanced.cfg -rw-r--r-- 1 root root 3460 Jun 10 16:11 /etc/sip-routerser.cfg
/etc/sip-router: total 140 drwxr-xr-x 2 root root 4096 Jun 24 14:40 ./ drwxr-xr-x 96 root root 12288 Jun 11 23:54 ../ -rw-r--r-- 1 root root 5744 Jun 10 16:11 dictionary.ser -rw-r--r-- 1 root root 5744 Jun 24 14:40 dictionary.sip-router -rw-r--r-- 1 root root 891 Jun 10 16:11 ser-selfsigned.key -rw-r--r-- 1 root root 1119 Jun 10 16:11 ser-selfsigned.pem -rw-r--r-- 1 root root 44977 Jun 24 14:16 sip-router-advanced.cfg -rw-r--r-- 1 root root 44977 Jun 24 14:40 sip-router-advanced.cfg.sample -rw-r--r-- 1 root root 3516 Jun 24 14:16 sip-router.cfg -rw-r--r-- 1 root root 3516 Jun 24 14:40 sip-router.cfg.sample -rw-r--r-- 1 root root 1779 Jun 24 14:40 tls.cfg Kamailio-151:~/sr/sip-router #
Edson.
Edson - Lists escreveu:
Hi, Juha...
Just downloaded a clean source and try a compilation.... At the end I got:
# TLS configuration touch //etc/sip-router//tls.cfg install -m 644 modules/tls/tls.cfg //etc/sip-router/ modules/tls/sip-router_cert.sh -d //etc/sip-router/ make: modules/tls/sip-router_cert.sh: Command not found make: *** [install-cfg] Error 127
and on the directory the file stills is named: ser_cert.sh
Edson.
Juha Heinanen escreveu:
Module: sip-router Branch: master Commit: 5d1a75a61b349690125db87c1e48b3de580613e6 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=5d1a75a6...
Author: Juha Heinanen jh@tutpro.com Committer: Juha Heinanen jh@tutpro.com Date: Wed Jun 24 15:44:10 2009 +0300
Core, etc, documentation: renamed ser to sip-router
Renamed ser to sip-router in Makefile, etc files and some core files.
Renamed some etc files from ser based name to sip-router based name.
INSTALL | 214 +++++++++++++----------- Makefile | 106 ++++++------ Makefile.defs | 2 +-
Edson - Lists writes:
Seems that it has other problems, since in /etc I found two files that shouldn't be there : Kamailio-151:~/sr/sip-router # l /etc/sip-router* -rw-r--r-- 1 root root 44865 Jun 10 16:11 /etc/sip-routerser-advanced.cfg -rw-r--r-- 1 root root 3460 Jun 10 16:11 /etc/sip-routerser.cfg
i don't know where those two come from. when i search 'advanced' at root dir, i get:
$ egrep advanced * ChangeLog: - advanced synchronization functions: atomic operations (inc, Makefile: > $(cfg_prefix)/$(cfg_dir)sip-router-advanced.cfg.sample Makefile: chmod 644 $(cfg_prefix)/$(cfg_dir)sip-router-advanced.cfg.sample Makefile: ! -f $(cfg_prefix)/$(cfg_dir)sip-router-advanced.cfg ]; then \ Makefile: mv -f $(cfg_prefix)/$(cfg_dir)sip-router-advanced.cfg.sample \ Makefile: $(cfg_prefix)/$(cfg_dir)sip-router-advanced.cfg; \
which look ok to me.
-- juha
Edson - Lists writes:
Just downloaded a clean source and try a compilation.... At the end I got:
# TLS configuration touch //etc/sip-router//tls.cfg install -m 644 modules/tls/tls.cfg //etc/sip-router/ modules/tls/sip-router_cert.sh -d //etc/sip-router/ make: modules/tls/sip-router_cert.sh: Command not found make: *** [install-cfg] Error 127
and on the directory the file stills is named: ser_cert.sh
try now again with modules/tls from git.
-- juha
Juha Heinanen escreveu:
Edson - Lists writes:
Just downloaded a clean source and try a compilation.... At the end I got:
# TLS configuration touch //etc/sip-router//tls.cfg install -m 644 modules/tls/tls.cfg //etc/sip-router/ modules/tls/sip-router_cert.sh -d //etc/sip-router/ make: modules/tls/sip-router_cert.sh: Command not found make: *** [install-cfg] Error 127
and on the directory the file stills is named: ser_cert.sh
try now again with modules/tls from git.
-- juha
Passed...
But now: #/usr/lib/sip-router/modules_k([^_])#//lib/sip-router/modules_k\1#g" \ -e "s#/usr/share/doc/sip-router/##g" \ < sip-router.8 > //share/man//man8/sip-router.8 /bin/sh: sip-router.8: No such file or directory make: *** [install-sip-router-man] Error 1
Edson.
Edson - Lists writes:
But now: #/usr/lib/sip-router/modules_k([^_])#//lib/sip-router/modules_k\1#g" \ -e "s#/usr/share/doc/sip-router/##g" \ < sip-router.8 > //share/man//man8/sip-router.8 /bin/sh: sip-router.8: No such file or directory
should be fixed now. what next?
-- juha
Juha Heinanen escreveu:
Edson - Lists writes:
But now: #/usr/lib/sip-router/modules_k([^_])#//lib/sip-router/modules_k\1#g" \ -e "s#/usr/share/doc/sip-router/##g" \ < sip-router.8 > //share/man//man8/sip-router.8 /bin/sh: sip-router.8: No such file or directory
should be fixed now. what next?
-- juha
Don't know... yet... waiting fresh compilation to finish... ;)
Edson.
Juha Heinanen escreveu:
Edson - Lists writes:
But now: #/usr/lib/sip-router/modules_k([^_])#//lib/sip-router/modules_k\1#g" \ -e "s#/usr/share/doc/sip-router/##g" \ < sip-router.8 > //share/man//man8/sip-router.8 /bin/sh: sip-router.8: No such file or directory
should be fixed now. what next?
-- juha
Another one:
#/usr/lib/sip-router/modules_k([^_])#//lib/sip-router/modules_k\1#g" \ -e "s#/usr/share/doc/sip-router/##g" \ < sip-router.cfg.5 > //share/man//man5/sip-router.cfg.5 /bin/sh: sip-router.cfg.5: No such file or directory make: *** [install-sip-router-man] Error 1
Edson.
Edson - Lists writes:
Another one:
#/usr/lib/sip-router/modules_k([^_])#//lib/sip-router/modules_k\1#g" \ -e "s#/usr/share/doc/sip-router/##g" \ < sip-router.cfg.5 > //share/man//man5/sip-router.cfg.5 /bin/sh: sip-router.cfg.5: No such file or directory make: *** [install-sip-router-man] Error 1
thanks for testing. that one should be now ok.
-- juha
Juha Heinanen escreveu:
Edson - Lists writes:
Another one:
#/usr/lib/sip-router/modules_k([^_])#//lib/sip-router/modules_k\1#g" \ -e "s#/usr/share/doc/sip-router/##g" \ < sip-router.cfg.5 > //share/man//man5/sip-router.cfg.5 /bin/sh: sip-router.cfg.5: No such file or directory make: *** [install-sip-router-man] Error 1
thanks for testing. that one should be now ok.
-- juha
Yep... this one is ok....
Here is the new one:
# FIXME: This is a hack, this should be (and will be) done properly in sed -e "s#^DEFAULT_SCRIPT_DIR.*#DEFAULT_SCRIPT_DIR="//share/sip-router/"#g" \ < scripts/mysql/sip-router_mysql.sh > //sbin//sip-router_mysql.sh /bin/sh: scripts/mysql/sip-router_mysql.sh: No such file or directory make: *** [install-utils] Error 1
Edson.
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Edson - Lists -
Iñaki Baz Castillo -
jh＠tutpro.com -
Juha Heinanen
-
Raúl Alexis Betancor Santana -
Victor Pascual Ávila