Adhearsion (アドヒアジョン) & Tropo presentation at Ruby Kaigi - Tokyo 2009

I just gave my talk at Ruby Kaigi in Tokyo Japan. The event is well organized and attended. I suppose that is a bit easier since Tokyo is the home of Ruby, and filled with 13 million people. Here are the slides: [slideshare id=1732968&doc=rubykaigijuly2009-tokyojapanese-090716214905-phpapp02]
Posted
 

Skype for Asterisk DOA, long live Skype for Asterisk!

Digium has responded to concerns about the value of Skype for Asterisk (SFA) after the announcement of
Media_httpjsgoeckefil_bubhv
Skype for SIP (SFS) last Monday. I would like to state for the record that I did not declare SFA dead, but raised the question. It is indisputable that the value of SFA is diminshed in light of the announcement of SFS, therein lies the opportunity to push for deeper integration to regain that ground. In the 'Voice On The Web - Skype in Your Business' public Skype chat, Skype did correct two items in the Digium post:
  • SFA can handle incoming Skype calls from any user on the Skype network.  SFS can receive incoming calls from Skype users only by statically mapping a Skype name to a SIP account.
  • SFA supports incoming calls directly from SkypeIn DID numbers.  SFS does not.
These are not differentiators unique to SFA, as they may both be done in SFA and SFS. With this correction we are left with four differentiators:
  • SFA can place calls to any user on the Skype network.  SFS cannot place calls to Skype users.
  • SFA includes support for Skype presence information.  SFS has no support for presence.
  • SFA includes buddy list management.  SFS has no buddy list management features.
  • SFA supports multiple media codecs including G.711 aLaw and uLaw as well as G.729.  Wide-band audio will be available in a near-term revision.  SFS supports only compressed telephony-grade G.729 media streams.
There is value here, which I have highlighted before. But the number of use cases where I now need SFA is signifcantly reduced now that SFS will be availalbe. The reason is that Asterisk of course supports SIP, so I may now use SFS to handle all inbound calls, and use SFA in the specific cases needed. For example, one channel license may provide all of the presence updates I need. The biggest advantage, SIP -> Skype User calls, may or may not be needed for your use cases, and if so maybe at a reduced number of channels now that you have SFS and may have a hybrid solution. Voxeo had the equivalent of SFS for a while now and hummed along happily providing useful applications. The point is not to declare SFA dead, but to highlight these points in the hopes that the opportunities for deeper integration and the associated benefits are clear. For SFA to overshadow the SFS announcement, I contend these features are needed:
  • Two-way chat via the Manager API
  • Extended presence support
  • SILK-codec support, which would require end-points (ie - SIP soft phones/hardware phones) embedding SILK
I understand that Digum and Skype need to get SFA to market, but a clear roadmap of what comes next and the timing would be immensly useful as developers look to place their bets. I applaud the work that Skype and Digium have been doing and the opening of the Skype network on multiple fronts. I just hope this is an opportunity to open the Skype network that little bit more. *UPDATE* Digium has changed their list of differentiators in the blog post, and have replaced one of the incorrect items with this one:
  • SFA calls are encrypted from end-to-end while SFS calls are delivered to the SFS endpoint devices (PBX) as unencrypted RTP streams.
This will be a short lived one, as while the SFS beta will be UDP/RTP, Skype have already committed to TLS/TCP and SRTP. So SFS will have the same ability for encrypted communications as SFA does.
Posted
 

Writing a Ruby app for Tropo

Media_httpjsgoeckefil_gmhby
Tropo is a great step in the right direction. Voice enabling your applications powered by a voice cloud is simple again. No need to mess with XML-based interfaces and get straight to writing your application with an effortless API. The first phase of Tropo allows you to write an application in Javascript, PHP, Groovy, Python or Ruby. To get started you may register for a free developer account on the Tropo website. After logging in you then have two ways you may deploy your applications. The first is to drop the script you have created on a web server and give Tropo a URL, the second is to post your script directly into Tropo with their free file hosting service. For this Ruby app we will be creating the file locally and dropping it on a web server for Tropo to fetch.

Read the rest of this post »

Posted
 

Adhearsion Presentation @ eComm - March 2009

Jay knocked it out of the park at eComm in Burlingame just now. [slideshare id=1101588&doc=ecomm09-final-090304133347-phpapp01]
Media_httpjsgoeckefil_dljgh
Posted
 

Using PHP to Invoke the Adhearsion API via REST

While Adhearsion is written in Ruby, every effort had been made to make it accessible from virtually any modern development language. The RPC subsystem in Adhearsion makes available several methods for accessing the APIs. Out of the box the RPC methods include Distributed Ruby, STOMP and REST. While we have not included SOAP/XML by default, the framework may be easily extended to make this method available as well.
Media_httpjsgoeckefil_gldfd
There are many websites and applications written in PHP. The great thing is that all of those applications may take advantage of what Adhearsion has to offer. In this example we show how to invoke the Adhearsion REST API from a PHP script that could be embedded in virtually any application. In this case a phone call will be placed between two parties, extension 303 and 304, using the Asterisk originate action. For example, this could be used to build a 'click to call' frame in an existing website. The PHP script creates an Adhearsion class to connect to Adhearsion and then invokes the originate as an HTTP POST with JSON (script available here):

Read the rest of this post »

Posted