VoicePHP: Indian Startup Marries Voice with PHP

45 Comments

hiww2Marrying web applications with voice has long been seen as the proverbial pot of gold: easy to dream about but hard to actually find. A few startups (and some large companies) are trying to solve the problem; some are using Voice XML, while others are betting on Adobe’s Flash. Today, TringMe, a Bangalore, India-based startup has thrown its hat in the ring by coming up with a way to marry VoIP with PHP, the lingua franca of the contemporary web. TringMe describes VoicePHP as an extension of PHP that now outputs voice instead of text and also takes input as voice instead of text. [digg=http://digg.com/tech_news/Indian_startup_arranges_a_marriage_of_VoIP_and_PHP]

Basically, VoicePHP is intended to do the same things as VoiceXML, but by using the familiar PHP programming methology. In doing so, it wants to attract a large pool of PHP-savvy developers and have them develop voice applications. (See how it works.) This is an even simpler approach than the one floated by Ribbit, a Silicon Valley-based company that was acquired by British Telecom in July 2008 for $105 million. Ribbit is betting on the large-scale adoption of Flash and hopes its Flash-centric solution would become the engine that powers web-voice applications.

The idea of VoicePHP seems disruptive in its simplicity. As TringMe puts it on the VoicePHP web site, “With VoicePHP, there’s no need to learn a new markup language, tags, attributes associated with VoiceXML. Widely and Freely available tools for developing, debugging PHP can be continued to use with VoicePHP.” It also means that an application written in VoicePHP can be accessed via Flash, instant messenger (like Google Talk), Mobile VoIP clients or even plain old phone lines. This gives TringMe an advantage over rivals that require Flash.*

voicephparch

VoicePHP also squares off against Twilio, a startup that allows developers to write apps that tap into Twilio’s backend to talk to any kind of phone. Twilio’s simpler version of VoiceXML allows developers to offer some core voice-related functions and helped it attact 1,000 or so developers during the first three days following its launch in late November 2008. Some of them are already using the service in an interesting ways. Voice(sneak) and Dwellicious are two such examples.

Twilio’s approach seemed simpler than the application programming interface (API) tactics that have been tried by others; VoIP companies offering APIs to their platforms have struggled to attract developers to their platforms. Although some VoIP services such as Phweet and iotum’s Calliflower are using TringMe’s API, the company is hoping that VoicePHP will remove all the complexity associated with API-based solutions.

VoicePHP goes well beyond the API paradigm and integrates voice into the language itself. One continues to use the same development, testing tools and implements PHP code as he is used to. There is no need to invoke special “vendor-specific” APIs.

Of course, TringMe isn’t doing this out of the goodness of its heart. It is betting that as VoicePHP grows popular, more and more web-voice application developers would use its VoIP platform, in turn helping TringMe earn money.

* If you are a VoIP developer and can offer your insights, I would appreciate your help. You can leave your thoughts in the comments area or email me using the contact form.

PS: GigaOM readers will get 50 beta invites for the hosted platform which will include one US phone number and phone credits to test the service. You can signup with TringMe & mention GigaOM. Their voice application will be immediately available from Flash, IM, Phone etc.

45 Comments

Lav

These new technologies are set to completely change the way we view telephony. Our company is presently looking into the alternatives to traditional phone lines, and Twilio so far looks the most promising, although VoicePHP is increasinly looking like a good alternative.

Kris subramanian

Hummingbytes is a startup based in Boston, MA that deals with the Communications Application marriage.Our communication gateway platform is on Windows .NET. So C# developers can develop voice applications using our development platform. SMS, Voice, IM are the supported channels.

Our current approach is to build real life applications on top of our platform and market the products. That is where we see a lot of business sense. Our latest product Mobile CRM is a web-based CRM system that uses our platform and delivers rich CRM functionality. Reaching customers and delivering content to customers has never been so easy.

Kris
CTO (HummingBytes)

Alex

Flash-based voip service flashphone.ru from Innovative Systems supports G.711, G.729 and H.263 for video. For next release Speex, H.263+ and H.264 promised.

Kulwinder Singh

TringMe:What codecs are you supporting for SIP calls currently? Do you have any plan to integrate the CELT codec in the near future? The use of CELT codec will improve the ASR engine performance drastically. Moreover, it uses less bandwidth than the ulaw codec.

-singh

Ed Pimentel

Though it is true VoiceXML is a mature standard, it comes with a lot of TelCO baggage that it makes it difficult (not impossible) to implement by Web2.x type companies.
I personally favor the RESTful API and Telegraph & FreeSwitch approach for large implementations.
It is refreshing to see the new methods to create Interactive VoIP2.x apps with Adobe Flash and the other Adobe Labs voip/p2p related products.

The comment about PHP not scaling and unmanageable code is no longer valid.
FlickR (LAMP based) supports billions of transactions per day and there any many PHP Web2.x services with the ability to scale just as well.
The exciting opportunity is that now it is now possible for 2 kids and a dog in garage to create to a voip2.x app or restfull framework and rise to become the next Nuance….or what TellMe should have become.

Yusuf Motiwala

Let me share some thoughts on this as well: We’ve used VoiceXML and have infact released Flash-based VoiceXML support in Oct 08 ( blog.tringme.com/announcing-flash-based-voicexml-platform ). The ability to access VoiceXML from Flash was the first of its kind offering and we received tremendous response on that front. “Voice is the mantra” and everyone wants to get into (using) it. Just like Jonathan puts it in his comments above, VoiceXML was complicated and painful for developers and it was during out interaction with some of them that we realized that IT HAS TO BE SIMPLER THAN VOICEXML. VoicePHP was a natural evolution from there. I mention this for fellow readers here with the intent of sharing the “need” to come up with VoicePHP.

It’s not REST APIs. It’s a pure replacement for VoiceXML engine which we developed earlier. PHP engine is tightly integrated with Voice. Hence PHP functions like echo, print and other IO functions can use voice as a medium. We’ve (TringMe) supported REST APIs for almost a year and understand the limitation that brings in which VoicePHP solves – the main one about making voice an integral part of the language.

As Apul has already mentioned, please revisit our updated “How It Works” section to get answers to some of the questions. I would love to talk at length & clarify with any of you in case you have any questions. Catch me on facebook (id=553302568) or gtalk:yusufimotiwala.

@Jonathan, thanks for your wishes. We certainly appreciate that. In your comment, you mention Voxeo offers CallXML. Since CallXML is a Voxeo specific markup language, aren’t you doing the exact same thing by providing a proprietary, albeit XML based, language? The intent is same, as you acknowledged, VoiceXML is complicated and painful – world needs a better non-XML alternative which is more intutive. XML is great for data representation and putting programming logic in XML is like fitting a square in a circle.

Reusability and component creation in XML appears like a forced approach. A mix of tags, javascript and such makes it difficult to read, manage and cleanly abstract reusable functionality in VoiceXML. A simple object oriented VoicePHP is below. Comparing this with VoiceXML code, one can see the simplicity and reusability in PHP.

// Assume that the incoming call is handled ….
// Prompt the caller to select a department …
$department = PromptAndSelectDepartment();

// User pressed a button to read out the department directory …
$directory = $department->PromptAndGetDirectory();

// User choose a number to be transferred to
$directory->PromptAndTransfer($extension);

Your response validates our argument for VoicePHP. Why do I, as a developer need to learn a different language (i.e. VoiceXML) and use specific “development tools for voice” (all of the ones you mention)? I already use certain tools for “development and programming” – ranging from Visual Studio, PHP, Eclipse etc etc. which are generic enough for me to do “all kinds of programming”. The entry barrier to voice programming has been the complexity associated with it, the tools, the technology and so on. In summary, for common developer, really no good development and test tools exist for VoiceXML.

Our intent with VoicePHP is to simplify that, to make it as commonplace as PHP. Our intent with TringMe was and continues to make voice accessible via Flash and REST APIs thereby providing intuitive alternatives to a VoiceXML which only caters to voice programming.

While we are on it, can you identify scenarios where you VoiceXML will work and VoicePHP will not?

@Mike, web side of things continues to apply. In other words, you aren’t doing anything special for voice. You use PHP as normally do, build your business logic and upload it to your web-server.

Yes, you can use it via HTTP request. The server executes the “voice” PHP script in a PHP interpreter and dynamic web content is still churned out. The benefit is that voice becomes and integral part of the dynamic content. We will soon enable the beta account for you.

BTW, your paragraph containing “What happens after I execute this? ” appeared incomplete. Was there a code snippet that didn’t show up? Not sure what you had in mind. But lets sync up so that we can answer any questions you have.

@David M, yeah, rich internet applications need voice tightly integrated and we are pretty excited about possible ways TringMe and VoicePHP can enable that.

@Kite Maker, It’s NOT REST but the PHP virtual machine executing voice. Using “echo” to output isn’t making a REST call. It’s a PHP function.

@whydna, just send a mail with a beta request and we will provide you one.

Let me share some more information ..
Scalability: TringMe’s platform is serving over a few tens of millions calls every month. Given the various options for originating and terminating calls (phones, browser, IM, Flash etc.), we’ve been able to scale very well to the demands and scalability and modularity continues to be our top priority.

Simplicity: Whether it was TringMe’s very first offering – Flash based telephony or the APIs, or any other TringMe product, making it easier to use has been a key goal for the entire team (the KISS principle).

In closing, its really interesting to see efforts across the spectrum to make voice a commonplace in the programming world (web etc.). Exciting times indeed lie ahead!

Yusuf
CEO, TringMe

David Knell

For another IVR-driven-by-your-favourite-scripting-language startup, have a look at http://www.softivr.com.

@Jonathan – Interested to read your comment on VoiceXML. I share your aversion to it, but am reluctantly coming round to the view that we’re going to have to support it: it may not be perfect for all of the reasons that you’ve mentioned, but it’s the only standard in town.

–Dave

Jonathan Taylor

A few quick points:

– The greatest strength of VoiceXML is the fact that its a standard. There are VoiceXML platforms available from over 40 different vendors today. VoiceXML delivers unmatched vendor choice in the telephony market.

– VoiceXML is enormously successful. At a minimum half of all new enterprise IVR deployments use VoiceXML. I’d guess about 20-30% of new non-enterprise voice applications use it as well.

– I am the CEO of Voxeo. Voxeo is arguably the largest provider of hosted SaaS VoiceXML services in the world today (over 75,000 ports or phone lines); and one of the top vendors of non-hosted on-premise VoiceXML (over 30,000 installations).

– I am also a developer. As a developer I do not like VoiceXML. Personally I find it to be too complicated, painful, and a barrier to entry for new developers as others have said.

– Just like web apps there are many ways or “religions” about how voice apps should be built. This is why Voxeo offers many other ways to create voice applications, including: CallXML – a very powerful yet simple XML based telephony markup; SIPMethod – a Java SIP Servlet platform; Designer – an extremely simple web-based Visio-like tool for voice apps; and VoiceObjects – a high end IDE and application server for complex voice apps.

– Offerings such as Adhearsion, IfByPhone, Twillio, and VoicePHP also offer great ways to build and in some cases deploy voice applications. Again speaking of developer, I prefer CallXML (Not surprising since I was the original implementer of the language ;) ), Adhearsion, and IfByPhone because I’ve never been much of a “tools guy” (I still edit web pages in vi) and because I prefer simplicity over complexity any time.

Some comments:

@Ravi – “Simplicity, why didn’t someone think of this before” … many have. See CallXML, Twillio, IfByPhone, etc above. Before the web you had things like Stylus VisualVoice (A visual basic control). The programming languages may have changed to Javascript, Ruby, or PHP… but its mostly all been done before. Telephony API’s, platforms, and languages tend to get complex over time because, well, telephony is complex. For example VoicePHP in its current form lets you do perhaps 5% of the things comprehensive telephony applications need to do. There is an 80/20 rule to common telephony features to be sure, but VoicePHP has a long way to go before it even gets close to the 80%. It will be exciting to see how VoicePHP scales to more complex apps while attempting to retain its simplicity… a goal that was close to my heart when designing CallXML.

@Tim Panton – Yes, for me the most exciting telephony apps are the ones that improve person to person communications. That said there is a massive requirement for automated IVR type applications out there. Call centers are expensive and unfortunately most consumers are unwilling to pay more for more human-based customer service. Fonolo, btw, is indeed very cool. One of my favorite new telephony apps.

@Vipin – the need and business case is the demand for IVR self-service type applications mentioned above. Unloved by many, but needed by many more. VoicePHP in its current form can address the most basic IVR type applications.

@Dameon Welch-Abernathy, @sergio – SMS support is indeed cool. Inbound SMS is a must! Really a dialog-based interaction is a dialog-based interaction wether you do it via the phone, SMS, or IM. As an industry we really need to stop creating medium specific dialog solutions and should create something new that can address all of the above… Voxeo is investing significantly in this area and will announce something this year.

@todd – absolutely… for full speech support a grammar language will need to be added to VoicePHP… and a TTS markup to deal with reading back addresses, etc. This is the slippery complexity slope of telephony platforms. It’s hard to maintain simplicity while addressing 80% of the required features. And yes, the big issue with things like VoicePHP is vendor lock in. Pre-VoiceXML we had many “simple” telephony API’s, platforms, and languages… over 50 in the 90’s. But most of those companies and/or products are dead now, and they were all proprietary… so the apps written with them all have to be replaced. VoiceXML is the Unix of telephony (good and bad). Like Unix it has succeeded with a depth and breadth nothing else has. Like Unix t has brought with it complexity, fragmentation, religious debates, and lots of arcane commands ;)

@Shai – Thanks for the Voxeo mention. I love what Fonolo is doing. We should meet up soon.

@Apul – Saying VoiceXML is not an object oriented programming language is like saying HTML is not an object oriented programming language. Neither are programming languages — they are markup languages. Like a web app, you write a VoiceXML application in a programming language such as PHP, Java, Ruby, C#, etc. There are a half-dozen fully object-oriented VoiceXML app generation frameworks out there. And so far as the “lack of voicexml development tools”, there are at least 15 different VoiceXML development tools out there: Audium/Cisco, Eclipse Voice Tools, OpenMethods openVXML, Vicorp, the SpeakRight framework, Voxeo Designer, Voxeo VoiceObjects, as well as vendor specific tools from Avaya, Nortel, Intervoice, Genesys, etc.

@Patrick – not sure where you’re looking, but VoiceXML is pervasive in the enterprise now. Over 40 platform vendors with tens of thousands of deployments and applications. Gartner, Datamonitor, and other leading industry analysts agree that the majority of new IVR systems sold in the next 5 years will be VoiceXML based. Voxeo alone had 22,069 people join our developer program and/or download our free VoiceXML/CCXML/CallXML platform in 2008 (http://www.voxeo.com/free)

@Kit Maker – yes, it is one of many new (but cool) REST-style API’s for telephony.

Best of luck to the TringMe guys and VoicePHP! These are exciting times for telephony application development.

-Jonathan

Mike Pultz

@Apul: thanks for your update; I read more on the website, and I think I understand a little better- but I also think the “web” side of things still apply.

Are you suggesting then, than you simply used PHP as a generic language framework, and it’s not necessarily meant to be used as a web-based scripting language? I realize many people use PHP as a command line scripting language, but I’d have to guess and say *most* use it via HTTP for dynamic web content.

From your example,

What happens after I execute this? how does the system handle the call? Does the native engine spawn a thread to handle the call events? Is this something I can use via a HTTP request (a la PHP code)?

We (fonolo.com) built something similar that we use in-house (never meant as a user-facing service), that we opted to use javascript as the scripting language- and we build native javascript methods to make calls, send dtmf, voice rec, etc.

I’ve signed up for a beta; can’t wait to try it.

Mike

David M

As web evolves and RIA become commonplace, voice will become a key requirement. The vision of integrating voice in all forms of RIA – flash, Ajax, PHP etc will be really important.
Hence I think voicephp has potential to make it big!!

Patrick

VoiceXML has been around for a while but I don’t see many applications using it. We still use the same old IVR system that’s been around for a while now. I think marrying Voice and PHP, as Om puts it could be the missing ingredient to make Voice applications more commonplace. I agree with Jason that voice is underserved in a lot of places.

I can’t but laugh at the comment that PHP code is crap :) It’s probably the coder and not the code, but I digress. Anyway, as a PHP developer, I think THIS IS THE WAY to bring-in voice into it – no APIs or anything else.

Good luck guys !

Sam Hotchkiss

Thanks for the mention! At voice(sneak), we’re having a lot of fun with the Twilio API, and believe that services like Twilio and VoicePHP have a lot of potential. We’re working on tying voice in with all of the traditional communication channels: phone, email, text messaging, twitter, facebook, etc, etc, to be a natural extension of your communications experience.

Best,
Sam
Founder, voice(sneak)

Sam Hotchkiss

Thanks for the mention! At voice(sneak), we’re having a lot of fun with the Twilio API, and believe that services like Twilio and VoicePHP have a lot of potential. We’re working on tying voice in with all of the traditional communication channels: phone, email, text messaging, twitter, facebook, etc, etc, to be a natural extension of your communications experience.

Apul Nahata

Glad to see a healthy discussion coming out of this post. Based on some of the confusion arising from the comments, we have updated the “How It Works” section accessible from the main page.

@Todd, I will not comment on the characteristics or adoption rate of PHP since as we all know, its prevalent and being used extensively. Since you continue to use PHP functions, there is *nothing* new to learn unless ofcourse you want to make calls or send messages for which we have added a handful of functions. echo just speaks and regular expression replaces grammar and we think it can’t get any simpler than that. PHP is an object oriented programming language, modular and reusable which you don’t find in VoiceXML. Not to forget about lack of development tools in VoiceXML.

@Jeff Haydn, we have been supporting Flash and REST APIs for almost an year now. Quite a few customers have been using it and might I say, using it happily. Our modular architecture has been very supportive for us to add incremental features.

@Jason, glad to hear about your efforts. Would love to touch-base with you.

@Vipin, its easier and cost effective to develop and deploy than VoiceXML. We are targeting the same customer space as VoiceXML.

@Mike, It’s not a PHP wrapper which calls some API but PHP engine tightly integrated with Voice. While PHP has been associated with web and it is natural to get confused with session etc, that’s not the case with VoicePHP where it runs as a native engine. Technically, it is far superior to PHP+AGI that you mention. I urge you to visit “How It Works” again.

Standards are only as good as they can be put to use :) TCP/IP started ruling the world even when standard described OSI model. Simplicity and acceptance do become key to products.

I also invite fellow readers to visit http://www.voicephp.com/whyvoicephp2.html link as well.

Apul Nahata

Glad to see a healthy discussion coming out of this post. Based on some of the confusion arising from the comments, we have updated the “How It Works” section and invite you to check the updated content at http://voicephp.com/howitworks.html

@Todd, I will not comment on the characteristics or adoption rate of PHP since as we all know, its prevalent and being used extensively. Since you continue to use PHP functions, there is *nothing* new to learn unless ofcourse you want to make calls or send messages for which we have added a handful of functions. echo just speaks and regular expression replaces grammar and we think it can’t get any simpler than that. PHP is an object oriented programming language, modular and reusable which you don’t find in VoiceXML. Not to forget about lack of development tools in VoiceXML.

@Jeff Haydn, we have been supporting Flash and REST APIs for almost an year now. Quite a few customers have been using it and might I say, using it happily. Our modular architecture has been very supportive for us to add incremental features.

@Jason, glad to hear about your efforts. Would love to touch-base with you.

@Vipin, its easier and cost effective to develop and deploy than VoiceXML. We are targeting the same customer space as VoiceXML.

@Mike, It’s not a PHP wrapper which calls some API but PHP engine tightly integrated with Voice. While PHP has been associated with web and it is natural to get confused with session etc, that’s not the case with VoicePHP where it runs as a native engine. Technically, it is far superior to PHP+AGI that you mention. I urge you to visit “How It Works” again.

Standards are only as good as they can be put to use :) TCP/IP started ruling the world even when standard described OSI model. Simplicity and acceptance do become key to products.

I also invite fellow readers to visit http://www.voicephp.com/whyvoicephp.html and http://www.voicephp.com/whyvoicephp2.html.

Shai Berger

In addition to TringMe, take a look at:
* IfByPhone lets you use HTML forms for voice control.
* Voxeo gives you hosted environment for VoiceXML/CCXML development.
* CloudVox (still somewhat stealthy) gives you a hosted environment for running Asterisk extensions.

In other words, there is a voice development of platform out there for every level of development skill. Which means a lot more creative uses of voice technologies will be showing up.

@Tim Panton: Thanks for the mention! Yes, I agree that people generally find it frustrating to talk to IVR systems. (We certainly get a lot of mail saying so!)

I see the trend of easy IVR development as good news for us at Fonolo. More IVRs means more demand for our “Deep Dialing” system which lets you navigate IVRs visually from the web or smart phone. (BTW, for anyone that hasn’t tried it out yet, we’re in open beta so head over to http://www.fonolo.com)

– Shai

CEO, Fonolo

Jason Goecke

It is good to see voice being served to a wider audience, as voice is under served in many of today’s evolving websites. Another framework to watch (full disclosure here, I am involved) is the Ruby-based Adhearsion (http://www.adhearsion.com) open source voice development framework.

I believe VoiceXML is a barrier to entry for many developers and an unnecessary set of constraints that fetters voice development on the web while creating unnecessary complexity. VoiceXML came about to ensure portability across proprietary platforms, and that is about the limit of its utility. The more that may be done to show that using a framework with the full force of the underlying language is a move in the right direction. Further, if the underlying framework is open source and may be downloaded, then you remove much of the concern about portability between proprietary solutions that VoiceXML is meant to guard against.

The key here will be ensuring that voice applications are shareable using facilities such as or Ruby’s Gems, Perl’s CPAN, etc. Therefore the voice framework needs to have a well defined component/plug-in capability that facilitates this. I will have to play around with VoicePHP to see how this may be done and if they are working to build a developer community to foster social development along the lines of GitHub.

Mike Pultz

It’s definitely an interesting idea, though the biggest problem with PHP (and most web-based languages), is the lack of persistency between requests, which, in this case, you need to keep the phone call alive, or for DTMF events.

I’m guessing that’s where the voicePHP server (in the diagram above) comes in; it would affectively act as a kind of PBX for the PHP API requests; maintaining the calls persistently, and the PHP requests would affectively poll this server for each request.

… but given this, I don’t really see how this is any different than simply writing a PHP wrapper around the existing tringme REST API? Which is pretty trivial (by design), and is probably already out there for download.

Not to mention you can already do this using Asterisk + various PHP API’s that use the manager interface (like http://code.google.com/p/asterisk-php-api/)

I’ve signed up for a beta account; I’m interested to see how well it works.

Jeff Haydn

On the VoiceXML side I agree with Todd. It has taken a while but the standards and implementation is fairly stable and simple. PHP can get ugly. The whole concept seems to be a liftoff of Ribbit and maybe ooma. The guys are claiming support for a mouthful – Adobe Flash, Mobile, IM or conventional phone. Demos may work but supporting multiple environments and versions is a nightmare and PHP is not going to scale.

Todd

Some thoughts:

1) PHP is a newbie language and most PHP code is just crap, voice apps have zero tolerance for crap.
2) If you do speech rec you need grammars, if you do tts you will need ssml, two more things to learn.
2a) Go download asterisk and use a PHP AGI script, oh by the way, I bet these guys are using some open source software.
3) VoiceXML is just tags and javascript, don’t you know javascript?
4) VoiceXML is portable, PHP is not. If these guys go out of business all your efforts are gone! Better off using something more standard!

Sergio

Wow! I can definitely see myself using this. VoiceXML is really painful, with all its tags making code unreadable and unmanageable. It feels trapped to do programming in VoiceXML.

Nothing seems simpler than the VoicePHP. As someone noted, receive SMS would be a cool addition. Good stuff!

Vipin

May I know what problem are they trying to solve with this? Target customer ? Business case?

Dameon Welch-Abernathy

Twilio’s stuff is dirt simple to understand and can be implemented by any competent web developer using ANY language they want.

The one thing I see in the VoicePHP API that is neat is SMS support. Too bad it’s only SEND SMS, receive SMS would rock!

Apul Nahata

Om, thanks for the great coverage.

For the benefit of the readers, I would like to add one more point to an already excellent article.

With VoicePHP, TringMe is probably the only platform to offer Flash and REST APIs and the support in PHP language to program for voice. So whether a developer wants to develop a Adobe Flash based voice application, Mobile (Symbian supported, IPhone coming soon) based voice application or a Voice application using conventional phone lines, all they require is to use VoicePHP. So whether it is Adobe Flash, Mobile, IM or conventional phone, TringMe’s platform supports it all

We will be demonstrating VoicePHP at HeadStart (http://headstart.in), Bangalore on Jan 9th,10th. Do drop by if you are around.

Alex

nice out of the box thinking.

We’ll have to see if it scales. Although Ribbit was never really put to the test either

Tim Panton

Om, I’d be happy to offer insight into this.
My main beef here is that Voice is best at person-to-person communications,
It looks like this api facilitates person-to-machine. The last thing we
need/want is more IVRs! Fonolo are heading in the right direction on this.

Ravi

Simplicity indeed! Why didn’t anyone think of this before? Awesome concept!!

Comments are closed.