[Serusers] SIP Express Bundle. Step 1.

Stefan Sayer stefan.sayer at iptego.com
Thu Feb 28 22:39:49 CET 2008



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



More information about the sr-users mailing list