Heheh, I really got you going, there, didn't I?! ;-)
I'm afraid you read too much into my comment there, and I think you know
that I agree with you by looking at what I have focused on.
My comment was really aimed at type of features, i.e. priorities in what
to add. Regardless of who is using SER, the reality is that SER's
development is driven by users and developers who do SIP for a living
and mostly within large-scale setups, not SMB, not small setup, not SIP
service provider-DIY-in-a-box people.
Thus, robust TLS support is prioritized, not UAC digest authentication.
And no, making it easy to change From headers is not prioritized.
That being said on the feature side, now the "make it simple for the
user side", Alfred Heggestad and I are working on SER Getting Started
for SER 2.0 with a whole lot of features and where features can be
selected from a list, and by using the m4 buildsystem, a ready-to-go
config is generated. We plan to create a web front-end as well.
Watch cvs -r rel_2_0_0 for updates and we appreciate any testing and
feedback we can get.
g-)
SIP wrote:
No offense, but that's a pretty short-sighted way
of looking at things.
Having worked in the computer business for almost two decades, I can
assure you, businesses don't use/buy products, no matter HOW stable they
are, if the total cost of ownership or production is too high -- this
includes buildout costs, development, maintenance, AND deployment.
If you build a product that's super-stable and super-fast, but
difficult, time consuming, or expensive to deploy, people will opt for a
different solution. That's just the way business works.
Take Cray Supercomputers as a prime example. Seymour Cray built this
fantastic supercomputer architecture, but didn't build any peripherals
for it or even an operating system, assuming that, if people had the raw
speed and power available, they'd be eager to use it even if they had to
build their own hardware/software. Eventually, after three tries at
three different companies, all with this same goal (he kept being forced
out of his own companies for his short-sighted and poor business ideas),
Seymour Cray's own company went bankrupt because people refused to buy
computers that were difficult to deploy, even if they were extremely fast.
Conforming to standards is good. Flexibility is also very good. But
ignoring things like ease of deployment (or *cough* documentation) is
basically just thumbing your nose at the people who actually use the
software. ;)
That being said, I do love the SER project, and I think SEMS has
incredible potential, but none of that will matter in the long run if
it's not made easy for people to use. One of the reasons so many people
go with things like Asterisk and then try and make it work like a SIP
proxy (which causes headaches galore) is because Asterisk is incredibly
easy to deploy, exceptionally well-documented, and has third-party
modules galore integrated into it to allow people to do all sorts of
things. SER and SEMS combined, on the other hand, while fast, powerful,
and a fully-featured SIP proxy/Media server combination, has sparse
documentation, is absolutely painful to deploy, and has only the very
basic few modules along with it, requiring that, for many features, you
write the module yourself.
While I would FAR prefer the core SER coders to continue their work on
making SER the stable, fast product it is, and in piecing together all
the SIP RFC weirdness into an actual product, SER/SEMS could not go
wrong by recruiting some more people to write modules, by making the
install create basic configs that work out of the box, and by having
detailed and clean documentation. I'd offer my services, but my C/C++
coding is laughable at best (it's been 15 years since I've done any real
C coding), and I honestly understand so little of the SER 2.0 stuff that
my writing documentation for it would be very BAD Idea (TM). If someone
(i.e. a coder who knows what's actually going on) were to write
framework documentation (much like the very sparse framework docs that
exist in the modules), however, I'd be happy to take a crack at making
it human-readable.
N.
Greger V. Teigre wrote:
:-) so, we agree then...
As a side-note:
iptel.org projects have a tendency to be directed
towards professionals. This has among other things, the implications
that conforming to standards is very important and that flexibility in
what you can do is more important than how simple it is to set up.
g-)
SIP wrote:
> That's actially a good analogy, Greger... The pickup truck is
> powerful, able to be used for many applications, and once you own one,
> everyone suddenly wants you around when they need some work done,
> whereas the Porsche is built for speed, is cramped, can't carry much,
> and is too expensive for any practical people to ever really purchase. ;)
>
> Mind you, that being said, we do all our conferences in SEMS. It's
> actually a metric ton easier to set up for conferencing than Asterisk
> (WHY is it you need a Zaptel timing interface for audio mixing, again?),
> can support massively more users (especially if some are in listen-only
> mode), and 'Just works.'
>
> N.
>
>
> Greger V. Teigre wrote:
>
>
>> Hm, I don't agree with that comparison ;-)
>> Asterisk is a PBX, SEMS is a platform for specific applications. There
>> are some common pre-developed applications that easily can be set up
>> (like a conference bridge, play announcements etc). However, if you
>> need a PBX with lots of features, you don't start with SEMS.
>>
>> I would rather compare Asterisk to a pick-up truck and SEMS to the
>> Porsche. Use the truck for pretty much any work, but the Porsche is
>> made for speed... :-)
>>
>> Using Asterisk as only a conference bridge and playing announcements
>> is like using the pick-up truck to move your 12-piece china...
>> g-)
>>
>> SIP wrote:
>>
>>
>>> Offers them? Yes. Offers them in a clean, friendly, usable package? Not
>>> so much yet.
>>>
>>> SEMS has raw capability, but if you want it to do many of the things
>>> Asterisk can do, you need to know how to code that yourself, or you're
>>> going to be digging about the code for documentation on features (since
>>> the current docs are not the world's greatest).
>>>
>>> Don't get me wrong, SEMS has its place, and is a constantly evolving
>>> work of art (we use SEMS for several things in our environment), but
>>> comparing SEMS to Asterisk is a bit like comparing a bunch of car parts
>>> to a Porsche.
>>>
>>> N.
>>>
>>>
>>> Fredrik Lundmark wrote:
>>>
>>>
>>>
>>>> I'm still learning myself, but SEMS (
iptel.org/sems) seems to offer
>>>> many of the media- and/or b2bua-functions that Asterisk do.
>>>>
>>>> ///Fredrik
>>>>
>>>>
>>>>
>>>> ----- Original Message ----- From: "SIP"
<sip(a)arcdiv.com>
>>>> To: "Nhadie" <nhadie(a)tbgi.net.ph>
>>>> Cc: <asterisk-users(a)lists.digium.com>om>;
<serusers(a)lists.iptel.org>
>>>> Sent: Thursday, August 23, 2007 1:38 PM
>>>> Subject: Re: [Serusers] why combine ser with asterisk
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Asterisk is an excellent PBX system, and makes a very good endpoint
in
>>>>> the SIP chain for all sorts of things -- IVR systems, voicemail
>>>>> applications, automated messages, etc.
>>>>>
>>>>> It has an extremely well-written CDR engine, so many people mesh it
with
>>>>> billing applications to produce accurate accounting information. It
also
>>>>> is fully aware of the media stream, which means it's capable of
cutting
>>>>> off a call mid-stream, injecting audio into the call, etc, etc.
>>>>>
>>>>> Programming for Asterisk addons can be easily done in just about any
>>>>> language, and it meshes well with the overall structure. Programming
for
>>>>> SER is... not so simple.
>>>>>
>>>>> As for running them both on the same box, the biggest problem would
be
>>>>> resources. Unlike SER, Asterisk is not designed to be a
carrier-grade
>>>>> SIP proxy. If you're actually proxying the media stream,
you'd be
>>>>> hard-pressed to squeeze more than 150 simultaneous calls out of
Asterisk
>>>>> on even the beefiest of hardware. Add SER to the same box, and you
will
>>>>> quickly run into resource problems in medium-sized environments. It
also
>>>>> doesn't have a lot of the SIP proxy functionality that SER has.
>>>>>
>>>>> If you're careful, you can configure Asterisk NOT to handle the
media
>>>>> stream and still use it for prepaid solutions (using astcc or
>>>>> asterisk-b2bua), and this will save you bandwidth (but you'll
still
>>>>> likely run into NAT issues that need to be dealt with somehow) and
still
>>>>> let you use Asterisk as an in-between point.
>>>>>
>>>>> Together, Asterisk and SER make a very powerful combination for
>>>>> providing a full suite of services to clientele, and each plays well
off
>>>>> the other's strengths.
>>>>>
>>>>> N.
>>>>>
>>>>>
>>>>>
>>>>> Nhadie wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> What's the advantage of combining ser with asterisk? I always
see
>>>>>> comments like using ser with asterisk is a very good solution
etc. etc.
>>>>>> the thing i liked with ser is that it does not do codec
translation,
>>>>>> which saves me cpu usage and also bandwidth. if i combine it
with
>>>>>> asterisk, would it not use codec translation?
>>>>>>
>>>>>> i also read that there is also a problem when ser and asterisk is
>>>>>> run on
>>>>>> the same machine, why is it so?
>>>>>> if use prepaid billing solution for asterisk like astcc, would i
>>>>>> then be
>>>>>> able to provide prepaid service?
>>>>>>
>>>>>> soryy for asking too much, i'd just like to really understand
it. Thank
>>>>>> You in advanced.
>>>>>>
>>>>>> Regards,
>>>>>> Nhadie
>>>>>> _______________________________________________
>>>>>> Serusers mailing list
>>>>>> Serusers(a)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
>>>>>
>>>>>
>>>>>
>>>>>
>>> _______________________________________________
>>> Serusers mailing list
>>> Serusers(a)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
>
>
>
>
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers