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 <t...@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 > -- _____________________________________________________________________ -- 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