[asterisk-users] Asterisk concurrent calls count
Steve Totaro
stotaro at totarotechnologies.com
Sun May 18 23:19:40 CDT 2008
On Sun, May 18, 2008 at 3:32 PM, Steve Edwards
<asterisk.org at sedwards.com> wrote:
> On Sun, 18 May 2008, Steve Totaro wrote:
>
>> On Sun, May 18, 2008 at 12:32 AM, Jay R. Ashworth <jra at baylink.com> wrote:
>>> On Sat, May 17, 2008 at 06:43:51PM -0400, Steve Totaro wrote:
>>>> Maybe next they will charge $250 for "conference bridge" capabilities.
>>>> It's a joke to cripple things that can be enabled by flicking a
>>>> switch.
>
> If a feature adds value to a product, the customer will pay more for it.
> If a feature increases your support cost, you will charge more for it.
I charge per hour. If they want the additional functionality, it must
be defined in the scope of work and they will pay for it based on my
hourly rate.
>
>> I guess I hate to see something I have viewed as such a huge paradigm
>> shift and disruptive force from selling boxes to selling knowledge.
>
> If I buy a bare DL380 from you, will it cost the same as a fully loaded
> DL380 configured, optimized, and guaranteed to handle 400 seats? I think
> you sell your "knowledge" as well as a "box" as well as your time.
>
I already addressed this in another post in this thread. Your
assumptions are incorrect on how I do business.
>> I do however, think that Digium should provide some rough concurrent
>> call figures and I guess that is how I got off topic on this SwitchVox
>> tangent. There are some common feature sets, especially when looking
>> at PBX functionality with or without Zap or transcoding hardware that
>> could be published (with a disclaimer of course). There are also
>> common server platforms but that is more of a moving target.
>
> Someone brought up the TPC benchmark. The purpose of the benchmark is to
> "standardize" a synthetic processing load to allow competing vendors to
> beat their chests. Who is competing with Digium? Where is the competition?
> It's not in software, its in hardware. Thus, the competitors are IBM,
> Dell, HP, Zonbu, etc. Since our marketplace is so small, the
> aforementioned vendors are not interested in the market so the burden
> falls to the interested parties -- us.
>
> If we can agree on a couple of benchmark scenarios, we can then test our
> hardware and post our results to the wiki in table and graph form.
>
> In the interest in starting the process, here are a couple of metrics I'd
> be interested in.
>
> ) What is the maximum number of simultaneous calls (1 on 1 conversations)
> that can be bridged before call quality is impaired>
>
> ) What is the maximum number of simultaneous calls that can be put into a
> single meetme conference before call quality is impaired>
>
> ) What is the maximum number of 3 person (agent, customer, supervisor)
> meetme conferences before call quality is impaired>
>
> How do you objectively measure call quality? Pass a sine wave at the upper
> and lower range of a human voice and compare the waveforms?
>
> How do you construct a "standard" benchmark test bed? 2 identical Asterisk
> systems, 1 beating on the other?
>
> These metrics should be run for each technology (IAX, SIP, TDM via T1, TDM
> via USB) as well as Asterisk version (1.2, 1.4, 1.6)
>
> There are a lot of variables (OS flavor, OS version, OS tweaks, gcc
> version, network interface and driver, etc.) that need to be identified
> and as we collect more samples we may discover that some of these
> variables are important and some are not. This implies that at least in
> the "beta" stage of developing a benchmark, submitters must "own" their
> samples and be willing to re-run tests as the benchmark is refined.
>
> Thanks in advance,
> ------------------------------------------------------------------------
> Steve Edwards sedwards at sedwards.com Voice: +1-760-468-3867 PST
> Newline Fax: +1-760-731-3000
>
Steve, I would like to discuss this more with you. Please contact me
offlist if you are interested in going forward or being involved.
Thanks,
Steve Totaro
More information about the asterisk-users
mailing list