Skype Rates and Least Cost Routing

Now that Skype is coming to the enterprise with Skype for Asterisk and Skype for SIP, they will need to enhance the data available for their calling rates. Enabling Least Cost Routing (LCR) is a must for any VoIP provider to the enterprise. LCR allows a phone system to determine, on a call by call basis, which VoIP provider to use based on the best rates associated to the country code or prefix being dialed. As of now Skype publishes a web page of calling rates based on the country name and the per minute rate including or excluding the tax. A few additional items are needed to make this usable for LCR systems:
  • The associated country code for each country (ie - '34' for Spain, '1' for the US, etc)
  • More granular prefixes where calling rates may differ (ie - '346' for Spanish mobiles, '336' for Frech mobiles, '1212' for NYC, '1712' for Iowa, etc)
  • Billing intervals
  • A file download in CSV, or similar format, for import into LCR systems
Of course, in the meantime it is easy enough to scrape the website and convert the available data into a more appropriate format. Here is an example, in Ruby, of how this may be done in a trivial way: [sourcecode language='ruby'] require 'rubygems' require 'open-uri' require 'nokogiri' require 'json' skype_rates = Hash.new skype_url = 'http://www.skype.com/prices/callrates/#allRatesTab' skype_htmldoc = Nokogiri::Hpricot(open(skype_url).read) (skype_htmldoc/'table.listing//tr.r1').each do |country| country_name = country.at('td').inner_html skype_rates.merge!({ country_name => { 'amount' => country.at('span.amount').inner_html.split(' country.at('span.vat').inner_html.split('JSON output as follows: [sourcecode language='javascript'] { "Bolivia-La Paz": { "amount":0.122, "vat":0.14 }, "Sweden - Mobile": { "amount":0.292, "vat":0.336 }, "Hong Kong": { "amount":0.021, "vat":0.024 } } [/sourcecode] You may then perform a Regular Expression against another data source to derive the appropriate country codes/prefixes and store those in your LCR system. A good example of the additional detail needed is provided by Flowroute. I have on my list of actions to create an Adhearsion component to provide LCR capabilities for any Adhearsion application. The plan is to support a wide number of VoIP providers and other data inputs as a part of this plug-in. In the meantime, it will be interesting to see how Skype goes about publishing their rates with additional details and formats for download. UPDATE @JimCanuck points out it is not just about least cost, but also about quality of termination. Skype has some interesting approaches to call quality. More here.
Posted
 

Skype for SIP == Skype for Asterisk DOA?

Today Skype announced Skype for SIP (SFS). Put simply, enterprise telephone systems may now interconnect with the
Media_httpjsgoeckefil_ahcau
Skype network to receive calls from the Skype network and place calls to SkypeOut. All without the need to install any special hardware or software on most modern enterprise phone systems (IP-PBXs to be more specific). Skype's new enterprise targeted connectivity uses SIP, the industry standard for VoIP interconnection. SIP already powers the bulk of Skype's revenue, via SkypeIn/SkypeOut, so this is a logical progression to take advantage of the large scale infrastructure already in place at Skype. This is a tremendous move by Skype and one I have contended for years was necessary for them to make headway in the enterprise. I applaud this step. There are plenty of great posts out there covering this already, including the one by @danyork on Disruptive Telephony. What does this mean for Skype for Asterisk (SFA) announced last September? At best the value of SFA has been signficantly reduced by this announcement. Previously SIP interconnection to the Skype cloud was given to the rarified group of larger players such as Voxeo, Tellme, Genesys and others. SFA was the first time this access was going to be brought to the world of open source telephony developers through Asterisk. This provided an immense opportunity for the Asterisk developer community to create new applications to take advantage of this, which lead me to invest time to participate in the closed beta for SFA still underway. The SFS announcement this morning has just marginalized SFA to applications that benefit from direct dialing of Skype users from Asterisk and from basic presence updates from the Skype network. Gone are the benefits of providing Skype/SkypeIn inbound calls to the enterprise, SkypeOut trunking, etc. More so, SFA is at a disadvantage since you will have to pay a per channel (simultaneous call) license fee on top of any SkypeIn/SkypeOut costs. Further, I suspect that the number of SFA channels available to a single account will be limited for the same reason that SFS does not do SIP to Skype dialing, so that no one may provide large scale alternatives to SkypeIn. All of this has really taken the wind out of the SFA sails before it even had a chance to make it to a public beta. Digium must now look to quickly add new features. Such as advanced presence information, instant messaging, the SILK codec and others, if they hope to salvage their own investment in the development of SFA to date. While I understand these things take time, the lethargy of getting the SFA to market does not bode well for rapidly trumping the SFS announcement. Time will tell.
Posted