[Serusers] SIP Express Bundle. Step 1.
Jai Rangi
jprangi at gmail.com
Fri Feb 29 08:27:08 CET 2008
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 at 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.
> > 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)
> 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 at arcdiv.com
> > <mailto:sip at 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 at lists.iptel.org <mailto:Serusers at lists.iptel.org>
> > >>>> http://lists.iptel.org/mailman/listinfo/serusers
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>
> > >> _______________________________________________
> > >> Serusers mailing list
> > >> Serusers at lists.iptel.org <mailto:Serusers at lists.iptel.org>
> > >> http://lists.iptel.org/mailman/listinfo/serusers
> > >>
> > >>
> > >>
> >
> > _______________________________________________
> > Serusers mailing list
> > Serusers at lists.iptel.org <mailto:Serusers at lists.iptel.org>
> > http://lists.iptel.org/mailman/listinfo/serusers
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Serusers mailing list
> > Serusers at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
>
> --
> Stefan Sayer
> VoIP Services
>
> stefan.sayer at iptego.com
> www.iptego.com
>
> iptego GmbH
> Am Borsigturm 40
> 13507 Berlin
> Germany
>
> Amtsgericht Charlottenburg, HRB 101010
> Geschaeftsfuehrer: Alexander Hoffmann
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20080228/216df84d/attachment.htm>
More information about the sr-users
mailing list