[asterisk-biz] The newest buzz word - cloud computing

Thu Feb 4 22:13:14 CST 2010

We have developed a product like Google Voice (based on Ajax):

www.codevoz.com/central-number/

Voicemail, Callrecording, CDR's, Manage conacts, Make calls, receive
calls to all your phones, SMS, etc...

is not VoIP, is via E1/T1's

Based on LAMP + Ajax + Asterisk.

Its pretty cool

Write me off-list to give you a username/password to play with the interface.

Have a nice day

2010/2/4 Troy Davis <troy at yort.com>:
> (Disclaimer: I run Cloudvox and I'm biased.  I'm also transparent, my
> biases are logical, and I deal with this stuff every day.)
>
>> I did lot of research on this subject.
>>
>> - Call recordings etc. will have latency and it will be not
>> manageable. You call records should first be stored internally and
>> then written out to S3 block. S3 block can be anywhere - west or east
>> and you will notice call degradation.
>
> Hi Praveen,
>
> I think between Pascal's email and your reply, the term "cloud
> computing" was transformed into "Amazon EC2."  Your reply raises
> performance considerations specific to Amazon Web Services (some of
> which I believe are not practical concerns, which I'll address below).
>
> This is one of the biggest problems we encounter: one person will
> mention "cloud computing," and someone else will interpret that as
> "The cloud platform(s) that I've had experience with" (usually EC2)
> and evaluate it accordingly.
>
> Some cloud-scale services use EC2 or other parts of the AWS stack,
> like S3 (file-based storage) or Cloudfront (content delivery).  Some
> don't touch AWS anywhere and are based on rented or colo'ed servers,
> or an internal datacenter.  Most are hybrids.
>
> I cringe when someone mentions EC2, Google AppEngine, and Rackspace
> Cloud or Engine Yard in the same sentence as if they're
> interchangeable equivalents (not at all) or even competitors (barely).
>
> If there's one thing to take away from this thread, it's that "cloud
> services" are more different than alike.  There are very few
> statements - about intended purpose, performance, reliability, or
> complexity - that hold true for all cloud services, and that's even
> more true of cloud telephony services.
>
>> - Voicemail is ok on S3
>>
>> - EC2 does not have any ETA and they really do not concentrate much on
>> jitter and latency.
>>
>> - The major bottleneck is Bandwidth in and out. If you are using G711
>> - you will start burning yourself. If you have low volume - there is
>> no point of using cloud.
>
> While EC2 has performance and cost tradeoffs, I don't believe an
> actual implementation would write raw call audio from EC2 to S3 in
> realtime (without spooling locally).  EC2 instances have local disk
> ("ephemeral storage") and mounted quasi-SAN block storage (elastic
> block storage or EBS) specifically to solve this problem.
>
> I don't mean to say there aren't pros and cons to AWS, just that
> compared to issues like fine-grained kernel timing under load, and
> lack of control of the dom0 environment, these aren't huge issues (and
> I say this as someone who does not base his business on AWS).
>
> The second point you raise is:
>
>> - Most of the APIs I have seen are jsut wrappers on Asteirsk AGI.
>> Nothing else. Check out http://www.invox.com if you are seeking to
>> build IVR components - just drag and drop. Click and click - your IVR
>> is ready. 40-50 voice mashups out of box. Visual designer. Supports 40
>> countries. Has inbuilt support for speech recognition, text to speech
>> etc.
>
> This is also a sweeping statement ("just wrappers on Asterisk AGI.
> Nothing else"), rolled up into a self-serving paragraph.
>
> If someone's looking for a drag-and-drop IVR authoring system, and
> they're comfortable being dependent on the vendor who makes that GUI
> environment, Invox might be a good fit (I've never used it).
>
> But I don't think it's useful to knock a solution that meets the needs
> of a huge number of people - AGI - to make your sales pitch.
> Companies happily handle tens of thousands of calls per day with AGI,
> probably hundreds of thousands: http://bit.ly/auPEMu
>
> Trivializing AGI ignores LumenVox, Visual Dialplan, Cepstral,
> Loquendo, Presence Technology, and others who have speech recognition,
> TTS, visual dialplan, and ICD/queuing on top of Asterisk.
>
> Maybe worse, it ignores the power of open-source libraries like
> Adhearsion, Asterisk-Java, or asterisk-perl: they let the app
> developer or entrepreneur hold the cards.  Create an Adhearsion or
> PHPAGI app, and if your current app environment doesn't work, just
> move.  If it doesn't have the features you want, ask, add it, pay
> someone to add it, or move.
>
> Controlling your own destiny is really powerful.  And in the right
> hands, "just AGI" is ridiculously powerful.
>
> I don't mean to knock using a GUI designer or a proprietary
> environment, either.  That's the right solution for some people.  But
> for companies with existing apps, or knowledge of PHP, Java, or
> another language, they already have developers who understand how to
> write and manage that app.  A GUI designer is not necessarily a
> strength, especially when it means being locked into a single-vendor
> solution.
>
> It's not a case of your product versus "just AGI" - neither is right
> for everyone.
>
>> - G729 may have transcoding issues on cloud. Also, if you are using
>> Speech recognition - G729 is no no.
>>
>> My 2 cents - cloud is not yet ready as they may have latency not
>> covered in their SLA and they charge bandwidth in/out.
>
> Sweeping statements like "cloud is not ready" simply lead to
> confusion.  It's like saying "Some pizza has olives.  I don't eat
> olives, so everyone needs to stop eating pizza, everywhere."
>
> I'd encourage folks to do some homework, ask, and ultimately, test for
> yourself.  The capital cost is low enough to do that now, both for
> cloud platforms and cloud telephony.
>
> Troy
>
> --
> Cloudvox  --  http://cloudvox.com/
> call your code: API-driven phone calls, in minutes
> Ruby/Adhearsion, HTTP/JSON, PHP, Asterisk-Java, SIP, and more
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-biz mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-biz
>