Hi,
This is to summarize my opinions about FC* distro use.
IMHO, I think FC* is best selection as it contains many more fixes than does the older CENTOS (based on 5). I have deployed several hundred FC* boxes in VoIP applications. This is over 10,000 active ports without "Enterprise" stability issues.
IMHO this project needs the quickest path to the Enterprise community regardless of the OS/distro used.
I suppose the ultimate question is who is our target? Ourselves, naturally. However, I suggest our target is not the bankers or major corporations with lots of rules and procedures. That group will never adopt SER until they have a commercial-grade support system to advise their IT folks what to do for every question they may have.
IMHO our initial target is those early adopters who are trying to create new businesses in telecomm or consulting-on-telecom. We want them to have a solid core that they can leverage into their new appliances and specialized applications.
The early adopters are risk-takers (This means us as well!) They demand an open box in which they can face the SIP world with some assurance of standards compliance while at the same time they can face their clients with something better, faster, cheaper, and innovative enough to get paid well for their efforts.
Making a technology "buy - in" decision at any point in time is only a check point - not a final resting place. IMHO, we are better off selecting an OS/distro effort that has a large share of both early adopters and long term commercial support - - - so long as it meets our current and future technical **AND** target market requirements. Research confirms that the RH/FC community is the largest community with name recognition and respect among both the "geek-innovator" community as well as the Enterprise community.
..mike..
As long as the environment can be built to be stable, I'm in complete agreement. While our initial adopters may be the tinkerers and the risk-takers, I'd say that a good number of those people already try out SER (and may ultimately choose something with less of a learning curve). The biggest market for a SER bundle in the long run is going to be those who want to get a carrier grade SIP proxy up and running quickly and easily. Who that might be is somewhat difficult to determine, but I dare say we don't want to position ourselves as building a bundle for those who're willing to take risks. ;)
That said, the decision for CentOS came about because it is simply a GPL-compliant duplicate distro of Red Hat Enterprise Linux -- the single most common and most popular distribution amongst people who run linux in a carrier-grade situation.
Fedora Core, being the test bed for RHEL, has the same structure but newer, slightly less-vetted packages. However, if we can ensure stability, then none of that matters and no one will really care what distro it's built upon (as long as it's familiar to the admins who manage it). If you say you can build a stable FC-based SER server, then I say we go for it.
Do we have a second to Mike's motion to use FC as the base distro?
Mike Trest - Personal wrote:
Hi,
This is to summarize my opinions about FC* distro use.
IMHO, I think FC* is best selection as it contains many more fixes than does the older CENTOS (based on 5). I have deployed several hundred FC* boxes in VoIP applications. This is over 10,000 active ports without "Enterprise" stability issues.
IMHO this project needs the quickest path to the Enterprise community regardless of the OS/distro used.
I suppose the ultimate question is who is our target? Ourselves, naturally. However, I suggest our target is not the bankers or major corporations with lots of rules and procedures. That group will never adopt SER until they have a commercial-grade support system to advise their IT folks what to do for every question they may have.
IMHO our initial target is those early adopters who are trying to create new businesses in telecomm or consulting-on-telecom. We want them to have a solid core that they can leverage into their new appliances and specialized applications.
The early adopters are risk-takers (This means us as well!) They demand an open box in which they can face the SIP world with some assurance of standards compliance while at the same time they can face their clients with something better, faster, cheaper, and innovative enough to get paid well for their efforts.
Making a technology "buy - in" decision at any point in time is only a check point - not a final resting place. IMHO, we are better off selecting an OS/distro effort that has a large share of both early adopters and long term commercial support - - - so long as it meets our current and future technical **AND** target market requirements. Research confirms that the RH/FC community is the largest community with name recognition and respect among both the "geek-innovator" community as well as the Enterprise community.
..mike..
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
If no one else is going to come forward and second/debate Mike's suggestion to use FC, and Mike's the man with the server, then I declare this project officially FC-based.
These are the people that have so far contacted me and are verified for working on the SER Bundle Project, and for what tasks I have them available:
Jai Rangi -- kickstart work in FC Arun Kumar -- flexible Samuel -- some time/flexible ram -- testing Mike Trest -- server, testing, FC wrangling
Tasks we still need to fill (some of which can be filled perhaps by the people listed above as flexible or others in the project):
Core: -SERWeb install/config -RTP Proxy install/config (for base RTP proxy package -- not strictly SER config) -SEMS w/voicemail, away announcement, and conferencing support install/config
Tools: All tools (ser_ctl, sipsak, tcpdump/ngrep, wireshark/tshark, sipp, sip_scenario, spyagent+sipspy
Also, with no install package for SER with a basic config, SER itself will have to be installed/scripted to install with a tailored config(ser-oob.cfg) for the correct system/parameters. I'm ASSUMING that will go into the basic core install scripts, so I didn't add it in up there, but if this is an invalid assumption, someone has to let me know
As you can see, if you're interested in being a part of this project and can contribute time to getting it going, there are plenty of areas left where we need people to help. Just let me know, and I'll add you to the list.
N.
Neil Fusillo wrote:
As long as the environment can be built to be stable, I'm in complete agreement. While our initial adopters may be the tinkerers and the risk-takers, I'd say that a good number of those people already try out SER (and may ultimately choose something with less of a learning curve). The biggest market for a SER bundle in the long run is going to be those who want to get a carrier grade SIP proxy up and running quickly and easily. Who that might be is somewhat difficult to determine, but I dare say we don't want to position ourselves as building a bundle for those who're willing to take risks. ;)
That said, the decision for CentOS came about because it is simply a GPL-compliant duplicate distro of Red Hat Enterprise Linux -- the single most common and most popular distribution amongst people who run linux in a carrier-grade situation.
Fedora Core, being the test bed for RHEL, has the same structure but newer, slightly less-vetted packages. However, if we can ensure stability, then none of that matters and no one will really care what distro it's built upon (as long as it's familiar to the admins who manage it). If you say you can build a stable FC-based SER server, then I say we go for it.
Do we have a second to Mike's motion to use FC as the base distro?
Mike Trest - Personal wrote:
Hi,
This is to summarize my opinions about FC* distro use.
IMHO, I think FC* is best selection as it contains many more fixes than does the older CENTOS (based on 5). I have deployed several hundred FC* boxes in VoIP applications. This is over 10,000 active ports without "Enterprise" stability issues.
IMHO this project needs the quickest path to the Enterprise community regardless of the OS/distro used.
I suppose the ultimate question is who is our target? Ourselves, naturally. However, I suggest our target is not the bankers or major corporations with lots of rules and procedures. That group will never adopt SER until they have a commercial-grade support system to advise their IT folks what to do for every question they may have.
IMHO our initial target is those early adopters who are trying to create new businesses in telecomm or consulting-on-telecom. We want them to have a solid core that they can leverage into their new appliances and specialized applications.
The early adopters are risk-takers (This means us as well!) They demand an open box in which they can face the SIP world with some assurance of standards compliance while at the same time they can face their clients with something better, faster, cheaper, and innovative enough to get paid well for their efforts.
Making a technology "buy - in" decision at any point in time is only a check point - not a final resting place. IMHO, we are better off selecting an OS/distro effort that has a large share of both early adopters and long term commercial support - - - so long as it meets our current and future technical **AND** target market requirements. Research confirms that the RH/FC community is the largest community with name recognition and respect among both the "geek-innovator" community as well as the Enterprise community.
..mike..
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
At 11:11 AM 2/28/2008, SIP wrote:
Tools: All tools (ser_ctl, sipsak, tcpdump/ngrep, wireshark/tshark, sipp, sip_scenario, spyagent+sipspy
I will install & maintain wireshark, tcpdump and any other standard linux packages. Anyone with specific version needs, just let me know.
I will need to lookup sipp, sip_scenario, spyagent,sipspy as I am not familiar with them. Anyone want to suggest a specifc version or URL for these?
..mike..
Just thinking loud...may be not feasible... but....
it would be great that the base would enable easily interconnecting to other already running systems coming from the base via TLS so it would create kind of "trusted" SER nodes. This way newcomers to "SIP providers world" would have an added value installing the base...I think that just installing the right certificates in the base would make things easier.
This made me think about how many features would the base include? *TLS *auth_identity *presence...
For all of them to work we need different instances of SER due to the ssl library incompatibility. How big are we gonna make the base?
Case we can deploy several TLS+auth_identiy running nodes it would be "easy" to add SPIT methods....
Maybe too far, Samuel.
2008/2/28, Mike Trest - Personal Mike@trest.com:
At 11:11 AM 2/28/2008, SIP wrote:
Tools: All tools (ser_ctl, sipsak, tcpdump/ngrep, wireshark/tshark, sipp, sip_scenario, spyagent+sipspy
I will install & maintain wireshark, tcpdump and any other standard linux packages. Anyone with specific version needs, just let me know.
I will need to lookup sipp, sip_scenario, spyagent,sipspy as I am not familiar with them. Anyone want to suggest a specifc version or URL for these?
..mike..
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Good ideas, Samuel, but I think too far ahead. Let's start with a base level SER system first and get that up and working with the basic core level apps. Once that's done, we can see what can easily be added (presence will be a big one, I'm sure, and TLS will have interest as well).
N.
samuel wrote:
Just thinking loud...may be not feasible... but....
it would be great that the base would enable easily interconnecting to other already running systems coming from the base via TLS so it would create kind of "trusted" SER nodes. This way newcomers to "SIP providers world" would have an added value installing the base...I think that just installing the right certificates in the base would make things easier.
This made me think about how many features would the base include? *TLS *auth_identity *presence...
For all of them to work we need different instances of SER due to the ssl library incompatibility. How big are we gonna make the base?
Case we can deploy several TLS+auth_identiy running nodes it would be "easy" to add SPIT methods....
Maybe too far, Samuel.
2008/2/28, Mike Trest - Personal <Mike@trest.com mailto:Mike@trest.com>:
At 11:11 AM 2/28/2008, SIP wrote: >Tools: >All tools (ser_ctl, sipsak, tcpdump/ngrep, wireshark/tshark, sipp, >sip_scenario, spyagent+sipspy I will install & maintain wireshark, tcpdump and any other standard linux packages. Anyone with specific version needs, just let me know. I will need to lookup sipp, sip_scenario, spyagent,sipspy as I am not familiar with them. Anyone want to suggest a specifc version or URL for these? ..mike.. _______________________________________________ Serusers mailing list Serusers@lists.iptel.org <mailto:Serusers@lists.iptel.org> http://lists.iptel.org/mailman/listinfo/serusers
Sounds like a really cool idea. Also a great value add. TLS is also one of those that people tend to just skip until they get more advanced. Having a pre-configured second SER instance with TLS for a secured iptel.org interconnect would really take the hassle out of setting up your own server. iptel.org is its own CA, so maybe a way to request an iptel.org signed certificate for your server?! ;-) g-)
samuel wrote:
Just thinking loud...may be not feasible... but....
it would be great that the base would enable easily interconnecting to other already running systems coming from the base via TLS so it would create kind of "trusted" SER nodes. This way newcomers to "SIP providers world" would have an added value installing the base...I think that just installing the right certificates in the base would make things easier.
This made me think about how many features would the base include? *TLS *auth_identity *presence...
For all of them to work we need different instances of SER due to the ssl library incompatibility. How big are we gonna make the base?
Case we can deploy several TLS+auth_identiy running nodes it would be "easy" to add SPIT methods....
Maybe too far, Samuel.
2008/2/28, Mike Trest - Personal <Mike@trest.com mailto:Mike@trest.com>:
At 11:11 AM 2/28/2008, SIP wrote: >Tools: >All tools (ser_ctl, sipsak, tcpdump/ngrep, wireshark/tshark, sipp, >sip_scenario, spyagent+sipspy I will install & maintain wireshark, tcpdump and any other standard linux packages. Anyone with specific version needs, just let me know. I will need to lookup sipp, sip_scenario, spyagent,sipspy as I am not familiar with them. Anyone want to suggest a specifc version or URL for these? ..mike.. _______________________________________________ Serusers mailing list Serusers@lists.iptel.org <mailto:Serusers@lists.iptel.org> http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
I think all of these are actually the union of what people use and suggested for inclusion and they overlap in functionality, so I assume a selection can be chosen. sipsak, sipp, tcpdump, ngrep, sip_scenario, and wireshark/tshark are probably those I have heard mentioned most often. But not much use having them there if people cannot use them (and it's easy for people to install more stuff as they become more advanced). As sip_scenario creates an html from a dump, maybe that's all that is required in the beginning? Turn on capturing, turn off, and generate scenario? g-)
Mike Trest - Personal wrote:
At 11:11 AM 2/28/2008, SIP wrote:
Tools: All tools (ser_ctl, sipsak, tcpdump/ngrep, wireshark/tshark, sipp, sip_scenario, spyagent+sipspy
I will install & maintain wireshark, tcpdump and any other standard linux packages. Anyone with specific version needs, just let me know.
I will need to lookup sipp, sip_scenario, spyagent,sipspy as I am not familiar with them. Anyone want to suggest a specifc version or URL for these?
..mike..
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
I would just suggest that you try to stay as distro-independent as possible, i.e. make it easy to switch to another distro and make it easy for people to bootstrap on another distro by looking at the dependencies (and maybe contribute their bootstrap script :-).
As for config file, the ser-oob.cfg and ser.cfg that is generated by the buildsystem (sip_router/etc/buildsystem) are quite close. The buildsystem has a configure script that can be run as part of the bootstrap (it creates an m4 config file for local) or a web-based front-end can generate the config file quite easily. As I'm the maintainer of the buildsystem, I can promise some support if the system needs some adaption or the config file needs updating. I cannot speak for ser-oob.cfg, but as the idea is to show-case the iptel.org free SIP service config, I assume it will be more static.
See config buildsystem docs: http://www.iptel.org/sip_express_router_configuration_buildsystem
I'll follow the discussions and contribute where and when I can. g-)
SIP wrote:
If no one else is going to come forward and second/debate Mike's suggestion to use FC, and Mike's the man with the server, then I declare this project officially FC-based.
These are the people that have so far contacted me and are verified for working on the SER Bundle Project, and for what tasks I have them available:
Jai Rangi -- kickstart work in FC Arun Kumar -- flexible Samuel -- some time/flexible ram -- testing Mike Trest -- server, testing, FC wrangling
Tasks we still need to fill (some of which can be filled perhaps by the people listed above as flexible or others in the project):
Core: -SERWeb install/config -RTP Proxy install/config (for base RTP proxy package -- not strictly SER config) -SEMS w/voicemail, away announcement, and conferencing support install/config
Tools: All tools (ser_ctl, sipsak, tcpdump/ngrep, wireshark/tshark, sipp, sip_scenario, spyagent+sipspy
Also, with no install package for SER with a basic config, SER itself will have to be installed/scripted to install with a tailored config(ser-oob.cfg) for the correct system/parameters. I'm ASSUMING that will go into the basic core install scripts, so I didn't add it in up there, but if this is an invalid assumption, someone has to let me know
As you can see, if you're interested in being a part of this project and can contribute time to getting it going, there are plenty of areas left where we need people to help. Just let me know, and I'll add you to the list.
N.
Neil Fusillo wrote:
As long as the environment can be built to be stable, I'm in complete agreement. While our initial adopters may be the tinkerers and the risk-takers, I'd say that a good number of those people already try out SER (and may ultimately choose something with less of a learning curve). The biggest market for a SER bundle in the long run is going to be those who want to get a carrier grade SIP proxy up and running quickly and easily. Who that might be is somewhat difficult to determine, but I dare say we don't want to position ourselves as building a bundle for those who're willing to take risks. ;)
That said, the decision for CentOS came about because it is simply a GPL-compliant duplicate distro of Red Hat Enterprise Linux -- the single most common and most popular distribution amongst people who run linux in a carrier-grade situation.
Fedora Core, being the test bed for RHEL, has the same structure but newer, slightly less-vetted packages. However, if we can ensure stability, then none of that matters and no one will really care what distro it's built upon (as long as it's familiar to the admins who manage it). If you say you can build a stable FC-based SER server, then I say we go for it.
Do we have a second to Mike's motion to use FC as the base distro?
Mike Trest - Personal wrote:
Hi,
This is to summarize my opinions about FC* distro use.
IMHO, I think FC* is best selection as it contains many more fixes than does the older CENTOS (based on 5). I have deployed several hundred FC* boxes in VoIP applications. This is over 10,000 active ports without "Enterprise" stability issues.
IMHO this project needs the quickest path to the Enterprise community regardless of the OS/distro used.
I suppose the ultimate question is who is our target? Ourselves, naturally. However, I suggest our target is not the bankers or major corporations with lots of rules and procedures. That group will never adopt SER until they have a commercial-grade support system to advise their IT folks what to do for every question they may have.
IMHO our initial target is those early adopters who are trying to create new businesses in telecomm or consulting-on-telecom. We want them to have a solid core that they can leverage into their new appliances and specialized applications.
The early adopters are risk-takers (This means us as well!) They demand an open box in which they can face the SIP world with some assurance of standards compliance while at the same time they can face their clients with something better, faster, cheaper, and innovative enough to get paid well for their efforts.
Making a technology "buy - in" decision at any point in time is only a check point - not a final resting place. IMHO, we are better off selecting an OS/distro effort that has a large share of both early adopters and long term commercial support - - - so long as it meets our current and future technical **AND** target market requirements. Research confirms that the RH/FC community is the largest community with name recognition and respect among both the "geek-innovator" community as well as the Enterprise community.
..mike..
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
While I'm all for being distro-agnostic, as we're looking to build an ISO that you boot from and that installs all the necessary stuff to get up and running, we have to pick one -- hence the choice. This way, we can ensure that the base system built is guaranteed to have all the pre-requisites, the libraries we KNOW will function without issue, the settings which make sense for a SER system, etc.
Building an installable package on a random system can run you into every sysadmin's least favourite pasttime -- hunting down the numerous pre-requisites, installing them, and working through the conflicts.
I'm all for a script that activates the build-system on bootstrap/post-install so it can build an oob cfg for the box in question. I just wanted to point out that that's one of the things needing doing. :)
N.
Greger Viken Teigre wrote:
I would just suggest that you try to stay as distro-independent as possible, i.e. make it easy to switch to another distro and make it easy for people to bootstrap on another distro by looking at the dependencies (and maybe contribute their bootstrap script :-).
As for config file, the ser-oob.cfg and ser.cfg that is generated by the buildsystem (sip_router/etc/buildsystem) are quite close. The buildsystem has a configure script that can be run as part of the bootstrap (it creates an m4 config file for local) or a web-based front-end can generate the config file quite easily. As I'm the maintainer of the buildsystem, I can promise some support if the system needs some adaption or the config file needs updating. I cannot speak for ser-oob.cfg, but as the idea is to show-case the iptel.org free SIP service config, I assume it will be more static.
See config buildsystem docs: http://www.iptel.org/sip_express_router_configuration_buildsystem
I'll follow the discussions and contribute where and when I can. g-)
SIP wrote:
If no one else is going to come forward and second/debate Mike's suggestion to use FC, and Mike's the man with the server, then I declare this project officially FC-based.
These are the people that have so far contacted me and are verified for working on the SER Bundle Project, and for what tasks I have them available:
Jai Rangi -- kickstart work in FC Arun Kumar -- flexible Samuel -- some time/flexible ram -- testing Mike Trest -- server, testing, FC wrangling
Tasks we still need to fill (some of which can be filled perhaps by the people listed above as flexible or others in the project):
Core: -SERWeb install/config -RTP Proxy install/config (for base RTP proxy package -- not strictly SER config) -SEMS w/voicemail, away announcement, and conferencing support install/config
Tools: All tools (ser_ctl, sipsak, tcpdump/ngrep, wireshark/tshark, sipp, sip_scenario, spyagent+sipspy
Also, with no install package for SER with a basic config, SER itself will have to be installed/scripted to install with a tailored config(ser-oob.cfg) for the correct system/parameters. I'm ASSUMING that will go into the basic core install scripts, so I didn't add it in up there, but if this is an invalid assumption, someone has to let me know
As you can see, if you're interested in being a part of this project and can contribute time to getting it going, there are plenty of areas left where we need people to help. Just let me know, and I'll add you to the list.
N.
Neil Fusillo wrote:
As long as the environment can be built to be stable, I'm in complete agreement. While our initial adopters may be the tinkerers and the risk-takers, I'd say that a good number of those people already try out SER (and may ultimately choose something with less of a learning curve). The biggest market for a SER bundle in the long run is going to be those who want to get a carrier grade SIP proxy up and running quickly and easily. Who that might be is somewhat difficult to determine, but I dare say we don't want to position ourselves as building a bundle for those who're willing to take risks. ;)
That said, the decision for CentOS came about because it is simply a GPL-compliant duplicate distro of Red Hat Enterprise Linux -- the single most common and most popular distribution amongst people who run linux in a carrier-grade situation.
Fedora Core, being the test bed for RHEL, has the same structure but newer, slightly less-vetted packages. However, if we can ensure stability, then none of that matters and no one will really care what distro it's built upon (as long as it's familiar to the admins who manage it). If you say you can build a stable FC-based SER server, then I say we go for it.
Do we have a second to Mike's motion to use FC as the base distro?
Mike Trest - Personal wrote:
Hi,
This is to summarize my opinions about FC* distro use.
IMHO, I think FC* is best selection as it contains many more fixes than does the older CENTOS (based on 5). I have deployed several hundred FC* boxes in VoIP applications. This is over 10,000 active ports without "Enterprise" stability issues.
IMHO this project needs the quickest path to the Enterprise community regardless of the OS/distro used.
I suppose the ultimate question is who is our target? Ourselves, naturally. However, I suggest our target is not the bankers or major corporations with lots of rules and procedures. That group will never adopt SER until they have a commercial-grade support system to advise their IT folks what to do for every question they may have.
IMHO our initial target is those early adopters who are trying to create new businesses in telecomm or consulting-on-telecom. We want them to have a solid core that they can leverage into their new appliances and specialized applications.
The early adopters are risk-takers (This means us as well!) They demand an open box in which they can face the SIP world with some assurance of standards compliance while at the same time they can face their clients with something better, faster, cheaper, and innovative enough to get paid well for their efforts.
Making a technology "buy - in" decision at any point in time is only a check point - not a final resting place. IMHO, we are better off selecting an OS/distro effort that has a large share of both early adopters and long term commercial support - - - so long as it meets our current and future technical **AND** target market requirements. Research confirms that the RH/FC community is the largest community with name recognition and respect among both the "geek-innovator" community as well as the Enterprise community.
..mike..
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
All,
This discussion can be endless if we keep planning about the features. Hey how about this, hey this will be cool, I use that tool, we must have it and list keeps going on. I would say lets start working. 1. Take any version of OS. 2. Install all basic packages for a server edition. 3. Install and document the prereqs for ser (Source)+sems (source) +mysql (RPM)+ serweb (Source)+serctl (source)+sipp (Source) +sipsak (Source/RPM). 4. To make it easy for every one, all these surces should with with the defaults RPMs installed by the Linux version. 5. Make sure we installed everythign in /usr/local/ with a --prefix option for all the packages. Another option can be add a user/group ser and installed everything in ~ser/install directory.
Once we have this working, then we can go on the next items in the list. Lots of things in the list are installed by Default
Once we have this, we can build the ks.cfg file with a post installation script that will take care of step 3). There goes the testing phase and rebuilding phase with additional packages.
My 2 cents.
-Jai
On Thu, Feb 28, 2008 at 10:47 AM, SIP sip@arcdiv.com wrote:
While I'm all for being distro-agnostic, as we're looking to build an ISO that you boot from and that installs all the necessary stuff to get up and running, we have to pick one -- hence the choice. This way, we can ensure that the base system built is guaranteed to have all the pre-requisites, the libraries we KNOW will function without issue, the settings which make sense for a SER system, etc.
Building an installable package on a random system can run you into every sysadmin's least favourite pasttime -- hunting down the numerous pre-requisites, installing them, and working through the conflicts.
I'm all for a script that activates the build-system on bootstrap/post-install so it can build an oob cfg for the box in question. I just wanted to point out that that's one of the things needing doing. :)
N.
Greger Viken Teigre wrote:
I would just suggest that you try to stay as distro-independent as possible, i.e. make it easy to switch to another distro and make it easy for people to bootstrap on another distro by looking at the dependencies (and maybe contribute their bootstrap script :-).
As for config file, the ser-oob.cfg and ser.cfg that is generated by the buildsystem (sip_router/etc/buildsystem) are quite close. The buildsystem has a configure script that can be run as part of the bootstrap (it creates an m4 config file for local) or a web-based front-end can generate the config file quite easily. As I'm the maintainer of the buildsystem, I can promise some support if the system needs some adaption or the config file needs updating. I cannot speak for ser-oob.cfg, but as the idea is to show-case the iptel.org free SIP service config, I assume it will be more static.
See config buildsystem docs: http://www.iptel.org/sip_express_router_configuration_buildsystem
I'll follow the discussions and contribute where and when I can. g-)
SIP wrote:
If no one else is going to come forward and second/debate Mike's suggestion to use FC, and Mike's the man with the server, then I
declare
this project officially FC-based.
These are the people that have so far contacted me and are verified for working on the SER Bundle Project, and for what tasks I have them
available:
Jai Rangi -- kickstart work in FC Arun Kumar -- flexible Samuel -- some time/flexible ram -- testing Mike Trest -- server, testing, FC wrangling
Tasks we still need to fill (some of which can be filled perhaps by the people listed above as flexible or others in the project):
Core: -SERWeb install/config -RTP Proxy install/config (for base RTP proxy package -- not strictly SER config) -SEMS w/voicemail, away announcement, and conferencing support install/config
Tools: All tools (ser_ctl, sipsak, tcpdump/ngrep, wireshark/tshark, sipp, sip_scenario, spyagent+sipspy
Also, with no install package for SER with a basic config, SER itself will have to be installed/scripted to install with a tailored config(ser-oob.cfg) for the correct system/parameters. I'm ASSUMING
that
will go into the basic core install scripts, so I didn't add it in up there, but if this is an invalid assumption, someone has to let me know
As you can see, if you're interested in being a part of this project
and
can contribute time to getting it going, there are plenty of areas left where we need people to help. Just let me know, and I'll add you to the list.
N.
Neil Fusillo wrote:
As long as the environment can be built to be stable, I'm in complete agreement. While our initial adopters may be the tinkerers and the risk-takers, I'd say that a good number of those people already try
out
SER (and may ultimately choose something with less of a learning curve). The biggest market for a SER bundle in the long run is going
to
be those who want to get a carrier grade SIP proxy up and running quickly and easily. Who that might be is somewhat difficult to determine, but I dare say we don't want to position ourselves as building a bundle for those who're willing to take risks. ;)
That said, the decision for CentOS came about because it is simply a GPL-compliant duplicate distro of Red Hat Enterprise Linux -- the
single
most common and most popular distribution amongst people who run linux in a carrier-grade situation.
Fedora Core, being the test bed for RHEL, has the same structure but newer, slightly less-vetted packages. However, if we can ensure stability, then none of that matters and no one will really care what distro it's built upon (as long as it's familiar to the admins who manage it). If you say you can build a stable FC-based SER server,
then
I say we go for it.
Do we have a second to Mike's motion to use FC as the base distro?
Mike Trest - Personal wrote:
Hi,
This is to summarize my opinions about FC* distro use.
IMHO, I think FC* is best selection as it contains many more fixes than does the older CENTOS (based on 5). I have deployed several hundred FC* boxes in VoIP applications. This is over 10,000 active ports without "Enterprise" stability issues.
IMHO this project needs the quickest path to the Enterprise community regardless of the OS/distro used.
I suppose the ultimate question is who is our target? Ourselves, naturally. However, I suggest our target is not the bankers or major corporations with lots of rules and procedures. That group will never adopt SER until they have a commercial-grade support system to advise their IT folks what to do for every question they
may have.
IMHO our initial target is those early adopters who are trying to create new businesses in telecomm or consulting-on-telecom. We want them to have a solid core that they can leverage into their new appliances and specialized applications.
The early adopters are risk-takers (This means us as well!) They demand an open box in which they can face the SIP world with some assurance of standards compliance while at the same time they can face their clients with something better, faster, cheaper, and innovative enough to get paid well for their efforts.
Making a technology "buy - in" decision at any point in time is only a check point - not a final resting place. IMHO, we are better off selecting an OS/distro effort that has a large share of both early adopters and long term commercial support - - - so long as it meets our current and future technical **AND** target market requirements. Research confirms that the RH/FC community is the largest community with name recognition and respect among both the "geek-innovator" community as well as the Enterprise community.
..mike..
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Jai Rangi wrote:
All,
This discussion can be endless if we keep planning about the features. Hey how about this, hey this will be cool, I use that tool, we must have it and list keeps going on. I would say lets start working.
- Take any version of OS.
- Install all basic packages for a server edition.
- Install and document the prereqs for ser (Source)+sems (source)
sems prereqs: g++ (>= 3.4) make
optional: libspeex (speex codec) liblame (mp3 file writing)
python (>= 2.4) (ivr, py_sems) sip4 (py_sems) mpg123 (mp3 playback) libresample (resampling) spandsp (other DTMF detector)
No source RPMs for the moment online. Getting sems source svn head: $ svn co https://svn.berlios.de/svnroot/repos/sems/trunk svn snapshot: $ wget http://ftp.iptel.org/pub/sems/daily-snapshots/sems-trunk-latest.tar.bz2
installing sems: cd sems-trunk ; PREFIX=/usr/local make install
(it is nicer to have all modules built but to make only the needed modules for vm+conf+anouncement: make -C core install PREFIX=/usr/local make -C apps install PREFIX=/usr/local \ modules=announcement conference voicemail )
some things to configure for voicemail+conference+announcement (todo: script this): /etc/sems/sems.conf: load_plugins=wav;ilbc;gsm;speex;adpcm;announcement;conference;voicemail sip_port=5070 /etc/sems/etc/voicemail.conf: smtp_server=mail smtp_port=25
thats it.
Stefan
+mysql (RPM)+ serweb (Source)+serctl (source)+sipp (Source) +sipsak (Source/RPM). 4. To make it easy for every one, all these surces should with with the defaults RPMs installed by the Linux version. 5. Make sure we installed everythign in /usr/local/ with a --prefix option for all the packages. Another option can be add a user/group ser and installed everything in ~ser/install directory.
Once we have this working, then we can go on the next items in the list. Lots of things in the list are installed by Default
Once we have this, we can build the ks.cfg file with a post installation script that will take care of step 3). There goes the testing phase and rebuilding phase with additional packages.
My 2 cents.
-Jai
On Thu, Feb 28, 2008 at 10:47 AM, SIP <sip@arcdiv.com mailto:sip@arcdiv.com> wrote:
While I'm all for being distro-agnostic, as we're looking to build an ISO that you boot from and that installs all the necessary stuff to get up and running, we have to pick one -- hence the choice. This way, we can ensure that the base system built is guaranteed to have all the pre-requisites, the libraries we KNOW will function without issue, the settings which make sense for a SER system, etc. Building an installable package on a random system can run you into every sysadmin's least favourite pasttime -- hunting down the numerous pre-requisites, installing them, and working through the conflicts. I'm all for a script that activates the build-system on bootstrap/post-install so it can build an oob cfg for the box in question. I just wanted to point out that that's one of the things needing doing. :) N. Greger Viken Teigre wrote: > I would just suggest that you try to stay as distro-independent as > possible, i.e. make it easy to switch to another distro and make it > easy for people to bootstrap on another distro by looking at the > dependencies (and maybe contribute their bootstrap script :-). > > As for config file, the ser-oob.cfg and ser.cfg that is generated by > the buildsystem (sip_router/etc/buildsystem) are quite close. The > buildsystem has a configure script that can be run as part of the > bootstrap (it creates an m4 config file for local) or a web-based > front-end can generate the config file quite easily. > As I'm the maintainer of the buildsystem, I can promise some support > if the system needs some adaption or the config file needs updating. > I cannot speak for ser-oob.cfg, but as the idea is to show-case the > iptel.org <http://iptel.org/> free SIP service config, I assume it will be more static. > > See config buildsystem docs: > http://www.iptel.org/sip_express_router_configuration_buildsystem > > I'll follow the discussions and contribute where and when I can. > g-) > > SIP wrote: >> If no one else is going to come forward and second/debate Mike's >> suggestion to use FC, and Mike's the man with the server, then I declare >> this project officially FC-based. >> >> These are the people that have so far contacted me and are verified for >> working on the SER Bundle Project, and for what tasks I have them available: >> >> Jai Rangi -- kickstart work in FC >> Arun Kumar -- flexible >> Samuel -- some time/flexible >> ram -- testing >> Mike Trest -- server, testing, FC wrangling >> >> Tasks we still need to fill (some of which can be filled perhaps by the >> people listed above as flexible or others in the project): >> >> Core: >> -SERWeb install/config >> -RTP Proxy install/config (for base RTP proxy package -- not strictly >> SER config) >> -SEMS w/voicemail, away announcement, and conferencing support >> install/config >> >> Tools: >> All tools (ser_ctl, sipsak, tcpdump/ngrep, wireshark/tshark, sipp, >> sip_scenario, spyagent+sipspy >> >> Also, with no install package for SER with a basic config, SER itself >> will have to be installed/scripted to install with a tailored >> config(ser-oob.cfg) for the correct system/parameters. I'm ASSUMING that >> will go into the basic core install scripts, so I didn't add it in up >> there, but if this is an invalid assumption, someone has to let me know >> >> >> As you can see, if you're interested in being a part of this project and >> can contribute time to getting it going, there are plenty of areas left >> where we need people to help. Just let me know, and I'll add you to the >> list. >> >> >> >> N. >> >> >> Neil Fusillo wrote: >> >>> As long as the environment can be built to be stable, I'm in complete >>> agreement. While our initial adopters may be the tinkerers and the >>> risk-takers, I'd say that a good number of those people already try out >>> SER (and may ultimately choose something with less of a learning >>> curve). The biggest market for a SER bundle in the long run is going to >>> be those who want to get a carrier grade SIP proxy up and running >>> quickly and easily. Who that might be is somewhat difficult to >>> determine, but I dare say we don't want to position ourselves as >>> building a bundle for those who're willing to take risks. ;) >>> >>> That said, the decision for CentOS came about because it is simply a >>> GPL-compliant duplicate distro of Red Hat Enterprise Linux -- the single >>> most common and most popular distribution amongst people who run linux >>> in a carrier-grade situation. >>> >>> Fedora Core, being the test bed for RHEL, has the same structure but >>> newer, slightly less-vetted packages. However, if we can ensure >>> stability, then none of that matters and no one will really care what >>> distro it's built upon (as long as it's familiar to the admins who >>> manage it). If you say you can build a stable FC-based SER server, then >>> I say we go for it. >>> >>> Do we have a second to Mike's motion to use FC as the base distro? >>> >>> >>> Mike Trest - Personal wrote: >>> >>> >>>> Hi, >>>> >>>> This is to summarize my opinions about FC* distro use. >>>> >>>> IMHO, I think FC* is best selection as it contains many more fixes >>>> than does the older CENTOS (based on 5). I have deployed several >>>> hundred FC* boxes in VoIP applications. This is over 10,000 active >>>> ports without "Enterprise" stability issues. >>>> >>>> IMHO this project needs the quickest path to the Enterprise community >>>> regardless of the OS/distro used. >>>> >>>> I suppose the ultimate question is who is our target? Ourselves, >>>> naturally. However, I suggest our target is not the bankers or >>>> major corporations with lots of rules and procedures. That group >>>> will never adopt SER until they have a commercial-grade support >>>> system to advise their IT folks what to do for every question they may have. >>>> >>>> IMHO our initial target is those early adopters who are trying to >>>> create new businesses in telecomm or consulting-on-telecom. We want >>>> them to have a solid core that they can leverage into their new >>>> appliances and specialized applications. >>>> >>>> The early adopters are risk-takers (This means us as well!) They >>>> demand an open box in which they can face the SIP world with some >>>> assurance of standards compliance while at the same time they can >>>> face their clients with something better, faster, cheaper, and >>>> innovative enough to get paid well for their efforts. >>>> >>>> Making a technology "buy - in" decision at any point in time is only >>>> a check point - not a final resting place. IMHO, we are better off >>>> selecting an OS/distro effort that has a large share of both early >>>> adopters and long term commercial support - - - so long as it meets >>>> our current and future technical **AND** target market >>>> requirements. Research confirms that the RH/FC community is the >>>> largest community with name recognition and respect among both the >>>> "geek-innovator" community as well as the Enterprise community. >>>> >>>> ..mike.. >>>> >>>> _______________________________________________ >>>> Serusers mailing list >>>> Serusers@lists.iptel.org <mailto:Serusers@lists.iptel.org> >>>> http://lists.iptel.org/mailman/listinfo/serusers >>>> >>>> >>>> >>> >>> >> >> _______________________________________________ >> Serusers mailing list >> Serusers@lists.iptel.org <mailto:Serusers@lists.iptel.org> >> http://lists.iptel.org/mailman/listinfo/serusers >> >> >> _______________________________________________ Serusers mailing list Serusers@lists.iptel.org <mailto:Serusers@lists.iptel.org> http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
All right now we are talking. Thank you Stefan, I have two points to add here, 1) We need to save the source version. Reason I say this is that we would not want to support different version in one bundle. For example, in the post installation script, the script will do every thing for sems_version.tar-gz file. So we will save the source code for all the packages in the Installation CD or ISO Image. Something. 2. You wrote " (it is nicer to have all modules built but to make only the needed)" We are building this bundle for corporate use. I would suggest to add all the modules (If not all then at least modules required for mid size businesses). CPU, RAM and hard drive is not the issue any more, so I think its OK if the module is there and people don't use it. Again my another 2 cents..
-Jai
On Thu, Feb 28, 2008 at 1:39 PM, Stefan Sayer stefan.sayer@iptego.com wrote:
Jai Rangi wrote:
All,
This discussion can be endless if we keep planning about the features. Hey how about this, hey this will be cool, I use that tool, we must have it and list keeps going on. I would say lets start working.
- Take any version of OS.
- Install all basic packages for a server edition.
- Install and document the prereqs for ser (Source)+sems (source)
sems prereqs: g++ (>= 3.4) make
optional: libspeex (speex codec) liblame (mp3 file writing)
python (>= 2.4) (ivr, py_sems) sip4 (py_sems) mpg123 (mp3 playback) libresample (resampling) spandsp (other DTMF detector)
No source RPMs for the moment online. Getting sems source svn head: $ svn co https://svn.berlios.de/svnroot/repos/sems/trunk svn snapshot: $ wget http://ftp.iptel.org/pub/sems/daily-snapshots/sems-trunk-latest.tar.bz2
installing sems: cd sems-trunk ; PREFIX=/usr/local make install
(it is nicer to have all modules built but to make only the needed modules for vm+conf+anouncement: make -C core install PREFIX=/usr/local make -C apps install PREFIX=/usr/local \ modules=announcement conference voicemail )
some things to configure for voicemail+conference+announcement (todo: script this): /etc/sems/sems.conf: load_plugins=wav;ilbc;gsm;speex;adpcm;announcement;conference;voicemail sip_port=5070 /etc/sems/etc/voicemail.conf: smtp_server=mail smtp_port=25
thats it.
Stefan
+mysql (RPM)+ serweb (Source)+serctl (source)+sipp (Source) +sipsak (Source/RPM). 4. To make it easy for every one, all these surces should with with the defaults RPMs installed by the Linux version. 5. Make sure we installed everythign in /usr/local/ with a --prefix option for all the packages. Another option can be add a user/group ser and installed everything in ~ser/install directory.
Once we have this working, then we can go on the next items in the list. Lots of things in the list are installed by Default
Once we have this, we can build the ks.cfg file with a post installation script that will take care of step 3). There goes the testing phase and rebuilding phase with additional packages.
My 2 cents.
-Jai
On Thu, Feb 28, 2008 at 10:47 AM, SIP <sip@arcdiv.com mailto:sip@arcdiv.com> wrote:
While I'm all for being distro-agnostic, as we're looking to buildan
ISO that you boot from and that installs all the necessary stuff toget
up and running, we have to pick one -- hence the choice. This way,we
can ensure that the base system built is guaranteed to have all the pre-requisites, the libraries we KNOW will function without issue,the
settings which make sense for a SER system, etc. Building an installable package on a random system can run you into every sysadmin's least favourite pasttime -- hunting down thenumerous
pre-requisites, installing them, and working through the conflicts. I'm all for a script that activates the build-system on bootstrap/post-install so it can build an oob cfg for the box in question. I just wanted to point out that that's one of the things needing doing. :) N. Greger Viken Teigre wrote: > I would just suggest that you try to stay as distro-independentas
> possible, i.e. make it easy to switch to another distro and makeit
> easy for people to bootstrap on another distro by looking at the > dependencies (and maybe contribute their bootstrap script :-). > > As for config file, the ser-oob.cfg and ser.cfg that is generatedby
> the buildsystem (sip_router/etc/buildsystem) are quite close. The > buildsystem has a configure script that can be run as part of the > bootstrap (it creates an m4 config file for local) or a web-based > front-end can generate the config file quite easily. > As I'm the maintainer of the buildsystem, I can promise somesupport
> if the system needs some adaption or the config file needsupdating.
> I cannot speak for ser-oob.cfg, but as the idea is to show-casethe
> iptel.org <http://iptel.org/> free SIP service config, I assume it will be more static. > > See config buildsystem docs: > http://www.iptel.org/sip_express_router_configuration_buildsystem > > I'll follow the discussions and contribute where and when I can. > g-) > > SIP wrote: >> If no one else is going to come forward and second/debate Mike's >> suggestion to use FC, and Mike's the man with the server, then I declare >> this project officially FC-based. >> >> These are the people that have so far contacted me and are verified for >> working on the SER Bundle Project, and for what tasks I have them available: >> >> Jai Rangi -- kickstart work in FC >> Arun Kumar -- flexible >> Samuel -- some time/flexible >> ram -- testing >> Mike Trest -- server, testing, FC wrangling >> >> Tasks we still need to fill (some of which can be filled perhaps by the >> people listed above as flexible or others in the project): >> >> Core: >> -SERWeb install/config >> -RTP Proxy install/config (for base RTP proxy package -- not strictly >> SER config) >> -SEMS w/voicemail, away announcement, and conferencing support >> install/config >> >> Tools: >> All tools (ser_ctl, sipsak, tcpdump/ngrep, wireshark/tshark,sipp,
>> sip_scenario, spyagent+sipspy >> >> Also, with no install package for SER with a basic config, SER itself >> will have to be installed/scripted to install with a tailored >> config(ser-oob.cfg) for the correct system/parameters. I'm ASSUMING that >> will go into the basic core install scripts, so I didn't add it in up >> there, but if this is an invalid assumption, someone has to let me know >> >> >> As you can see, if you're interested in being a part of this project and >> can contribute time to getting it going, there are plenty of areas left >> where we need people to help. Just let me know, and I'll add you to the >> list. >> >> >> >> N. >> >> >> Neil Fusillo wrote: >> >>> As long as the environment can be built to be stable, I'm in complete >>> agreement. While our initial adopters may be the tinkerers andthe
>>> risk-takers, I'd say that a good number of those people already try out >>> SER (and may ultimately choose something with less of alearning
>>> curve). The biggest market for a SER bundle in the long run is going to >>> be those who want to get a carrier grade SIP proxy up andrunning
>>> quickly and easily. Who that might be is somewhat difficult to >>> determine, but I dare say we don't want to position ourselvesas
>>> building a bundle for those who're willing to take risks. ;) >>> >>> That said, the decision for CentOS came about because it is simply a >>> GPL-compliant duplicate distro of Red Hat Enterprise Linux -- the single >>> most common and most popular distribution amongst people who run linux >>> in a carrier-grade situation. >>> >>> Fedora Core, being the test bed for RHEL, has the same structure but >>> newer, slightly less-vetted packages. However, if we can ensure >>> stability, then none of that matters and no one will really care what >>> distro it's built upon (as long as it's familiar to the adminswho
>>> manage it). If you say you can build a stable FC-based SER server, then >>> I say we go for it. >>> >>> Do we have a second to Mike's motion to use FC as the basedistro?
>>> >>> >>> Mike Trest - Personal wrote: >>> >>> >>>> Hi, >>>> >>>> This is to summarize my opinions about FC* distro use. >>>> >>>> IMHO, I think FC* is best selection as it contains many morefixes
>>>> than does the older CENTOS (based on 5). I have deployedseveral
>>>> hundred FC* boxes in VoIP applications. This is over 10,000 active >>>> ports without "Enterprise" stability issues. >>>> >>>> IMHO this project needs the quickest path to the Enterprise community >>>> regardless of the OS/distro used. >>>> >>>> I suppose the ultimate question is who is our target?Ourselves,
>>>> naturally. However, I suggest our target is not the bankersor
>>>> major corporations with lots of rules and procedures. Thatgroup
>>>> will never adopt SER until they have a commercial-gradesupport
>>>> system to advise their IT folks what to do for every question they may have. >>>> >>>> IMHO our initial target is those early adopters who are tryingto
>>>> create new businesses in telecomm or consulting-on-telecom. We want >>>> them to have a solid core that they can leverage into theirnew
>>>> appliances and specialized applications. >>>> >>>> The early adopters are risk-takers (This means us as well!)They
>>>> demand an open box in which they can face the SIP world withsome
>>>> assurance of standards compliance while at the same time theycan
>>>> face their clients with something better, faster, cheaper, and >>>> innovative enough to get paid well for their efforts. >>>> >>>> Making a technology "buy - in" decision at any point in time is only >>>> a check point - not a final resting place. IMHO, we are better off >>>> selecting an OS/distro effort that has a large share of bothearly
>>>> adopters and long term commercial support - - - so long as it meets >>>> our current and future technical **AND** target market >>>> requirements. Research confirms that the RH/FC community isthe
>>>> largest community with name recognition and respect among boththe
>>>> "geek-innovator" community as well as the Enterprisecommunity.
>>>> >>>> ..mike.. >>>> >>>> _______________________________________________ >>>> Serusers mailing list >>>> Serusers@lists.iptel.org <mailto:Serusers@lists.iptel.org> >>>> http://lists.iptel.org/mailman/listinfo/serusers >>>> >>>> >>>> >>> >>> >> >> _______________________________________________ >> Serusers mailing list >> Serusers@lists.iptel.org <mailto:Serusers@lists.iptel.org> >> http://lists.iptel.org/mailman/listinfo/serusers >> >> >> _______________________________________________ Serusers mailing list Serusers@lists.iptel.org <mailto:Serusers@lists.iptel.org> http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Stefan Sayer VoIP Services
stefan.sayer@iptego.com www.iptego.com
iptego GmbH Am Borsigturm 40 13507 Berlin Germany
Amtsgericht Charlottenburg, HRB 101010 Geschaeftsfuehrer: Alexander Hoffmann
Hello,
Jai Rangi wrote:
All right now we are talking. Thank you Stefan, I have two points to add here,
- We need to save the source version. Reason I say this is that we
would not want to support different version in one bundle. For example, in the post installation script, the script will do every thing for sems_version.tar-gz file. So we will save the source code for all the packages in the Installation CD or ISO Image. Something.
yes of course. Only we are not too far away from a new sems release, and I would definitely want to go with that one, as it is probably much simpler to use.
- You wrote " (it is nicer to have all modules built but to make only
the needed)" We are building this bundle for corporate use. I would suggest to add all the modules (If not all then at least modules required for mid size businesses). CPU, RAM and hard drive is not the issue any more, so I think its OK if the module is there and people don't use it.
yes I think so too.
Stefan
Again my another 2 cents..
-Jai
Good summary...I just had few spare minutes at work and decided to send that email.
I can't recall right now whehter we have discussed the option of creating in parallel a vmware/xen image so people can start using it in their favorite virtual solution...more things for the future (?)
looking forward start installing/testing/documenting, Sam.
2008/2/28, Jai Rangi jprangi@gmail.com:
All,
This discussion can be endless if we keep planning about the features. Hey how about this, hey this will be cool, I use that tool, we must have it and list keeps going on. I would say lets start working.
- Take any version of OS.
- Install all basic packages for a server edition.
- Install and document the prereqs for ser (Source)+sems (source) +mysql
(RPM)+ serweb (Source)+serctl (source)+sipp (Source) +sipsak (Source/RPM). 4. To make it easy for every one, all these surces should with with the defaults RPMs installed by the Linux version. 5. Make sure we installed everythign in /usr/local/ with a --prefix option for all the packages. Another option can be add a user/group ser and installed everything in ~ser/install directory.
Once we have this working, then we can go on the next items in the list. Lots of things in the list are installed by Default
Once we have this, we can build the ks.cfg file with a post installation script that will take care of step 3). There goes the testing phase and rebuilding phase with additional packages.
My 2 cents.
-Jai
On Thu, Feb 28, 2008 at 10:47 AM, SIP sip@arcdiv.com wrote:
While I'm all for being distro-agnostic, as we're looking to build an ISO that you boot from and that installs all the necessary stuff to get up and running, we have to pick one -- hence the choice. This way, we can ensure that the base system built is guaranteed to have all the pre-requisites, the libraries we KNOW will function without issue, the settings which make sense for a SER system, etc.
Building an installable package on a random system can run you into every sysadmin's least favourite pasttime -- hunting down the numerous pre-requisites, installing them, and working through the conflicts.
I'm all for a script that activates the build-system on bootstrap/post-install so it can build an oob cfg for the box in question. I just wanted to point out that that's one of the things needing doing. :)
N.
Greger Viken Teigre wrote:
I would just suggest that you try to stay as distro-independent as possible, i.e. make it easy to switch to another distro and make it easy for people to bootstrap on another distro by looking at the dependencies (and maybe contribute their bootstrap script :-).
As for config file, the ser-oob.cfg and ser.cfg that is generated by the buildsystem (sip_router/etc/buildsystem) are quite close. The buildsystem has a configure script that can be run as part of the bootstrap (it creates an m4 config file for local) or a web-based front-end can generate the config file quite easily. As I'm the maintainer of the buildsystem, I can promise some support if the system needs some adaption or the config file needs updating. I cannot speak for ser-oob.cfg, but as the idea is to show-case the iptel.org free SIP service config, I assume it will be more static.
See config buildsystem docs: http://www.iptel.org/sip_express_router_configuration_buildsystem
I'll follow the discussions and contribute where and when I can. g-)
SIP wrote:
If no one else is going to come forward and second/debate Mike's suggestion to use FC, and Mike's the man with the server, then I
declare
this project officially FC-based.
These are the people that have so far contacted me and are verified
for
working on the SER Bundle Project, and for what tasks I have them
available:
Jai Rangi -- kickstart work in FC Arun Kumar -- flexible Samuel -- some time/flexible ram -- testing Mike Trest -- server, testing, FC wrangling
Tasks we still need to fill (some of which can be filled perhaps by
the
people listed above as flexible or others in the project):
Core: -SERWeb install/config -RTP Proxy install/config (for base RTP proxy package -- not strictly SER config) -SEMS w/voicemail, away announcement, and conferencing support install/config
Tools: All tools (ser_ctl, sipsak, tcpdump/ngrep, wireshark/tshark, sipp, sip_scenario, spyagent+sipspy
Also, with no install package for SER with a basic config, SER itself will have to be installed/scripted to install with a tailored config(ser-oob.cfg) for the correct system/parameters. I'm ASSUMING
that
will go into the basic core install scripts, so I didn't add it in up there, but if this is an invalid assumption, someone has to let me
know
As you can see, if you're interested in being a part of this project
and
can contribute time to getting it going, there are plenty of areas
left
where we need people to help. Just let me know, and I'll add you to
the
list.
N.
Neil Fusillo wrote:
As long as the environment can be built to be stable, I'm in
complete
agreement. While our initial adopters may be the tinkerers and the risk-takers, I'd say that a good number of those people already try
out
SER (and may ultimately choose something with less of a learning curve). The biggest market for a SER bundle in the long run is
going to
be those who want to get a carrier grade SIP proxy up and running quickly and easily. Who that might be is somewhat difficult to determine, but I dare say we don't want to position ourselves as building a bundle for those who're willing to take risks. ;)
That said, the decision for CentOS came about because it is simply a GPL-compliant duplicate distro of Red Hat Enterprise Linux -- the
single
most common and most popular distribution amongst people who run
linux
in a carrier-grade situation.
Fedora Core, being the test bed for RHEL, has the same structure but newer, slightly less-vetted packages. However, if we can ensure stability, then none of that matters and no one will really care
what
distro it's built upon (as long as it's familiar to the admins who manage it). If you say you can build a stable FC-based SER server,
then
I say we go for it.
Do we have a second to Mike's motion to use FC as the base distro?
Mike Trest - Personal wrote:
Hi,
This is to summarize my opinions about FC* distro use.
IMHO, I think FC* is best selection as it contains many more fixes than does the older CENTOS (based on 5). I have deployed several hundred FC* boxes in VoIP applications. This is over 10,000 active ports without "Enterprise" stability issues.
IMHO this project needs the quickest path to the Enterprise
community
regardless of the OS/distro used.
I suppose the ultimate question is who is our target? Ourselves, naturally. However, I suggest our target is not the bankers or major corporations with lots of rules and procedures. That group will never adopt SER until they have a commercial-grade support system to advise their IT folks what to do for every question they
may have.
IMHO our initial target is those early adopters who are trying to create new businesses in telecomm or consulting-on-telecom. We
want
them to have a solid core that they can leverage into their new appliances and specialized applications.
The early adopters are risk-takers (This means us as well!) They demand an open box in which they can face the SIP world with some assurance of standards compliance while at the same time they can face their clients with something better, faster, cheaper, and innovative enough to get paid well for their efforts.
Making a technology "buy - in" decision at any point in time is
only
a check point - not a final resting place. IMHO, we are better
off
selecting an OS/distro effort that has a large share of both early adopters and long term commercial support - - - so long as it meets our current and future technical **AND** target market requirements. Research confirms that the RH/FC community is the largest community with name recognition and respect among both the "geek-innovator" community as well as the Enterprise community.
..mike..
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Greger Viken Teigre -
Jai Rangi -
Mike Trest - Personal -
Neil Fusillo -
samuel -
SIP -
Stefan Sayer