28 Feb
2008
28 Feb
'08
11:39 p.m.
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(a)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:
--
Stefan Sayer
VoIP Services
stefan.sayer(a)iptego.com
www.iptego.com
iptego GmbH
Am Borsigturm 40
13507 Berlin
Germany
Amtsgericht Charlottenburg, HRB 101010
Geschaeftsfuehrer: Alexander Hoffmann
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(a)lists.iptel.org <mailto:Serusers@lists.iptel.org>
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> Serusers mailing list
> Serusers(a)lists.iptel.org <mailto:Serusers@lists.iptel.org>
> http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org <mailto:Serusers@lists.iptel.org>
http://lists.iptel.org/mailman/listinfo/serusers
------------------------------------------------------------------------
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers