Early impressions of Skype for SIP (SfS)

Media_httpjsgoeckefil_kmnxa
The day has finally come, I have been able to place a SIP call directly to and from the Skype network via a Skype service. I received my Skype for SIP (SfS) closed beta credentials yesterday and immediately set to work configuring endpoints to start making calls. The first step was to use an XLite Softphone to connect to the Skype SIP proxy. Then I graduated to connecting an Asterisk server. While there were some initial issues, Skype worked with the beta testers and had all of the major elements working by the end of the first day. I am impressed by how few issues there actually are, but I guess that is to be expected since this service leverages the same infrastructure behind SkypeOut and SkypeIn. Those services have been around for years and make up some of Skype's core revenue generating business. Here was what I was able to do so far:
  • Asterisk/XLite -> SIP -> SkypeOut -> PSTN (w/G711 codec)
  • PSTN -> SkypeIn -> SIP -> Asterisk/XLite (w/G729 codec)
  • Skype User -> SIP -> Asterisk/XLite
(Note: What I will not be able to try is 'Asterisk/Xlite -> SIP -> Skype User' since this is intentionally blocked by Skype. I presume this is to protect their SkypeIn business by blocking the ability to create a competing alternative.) If you have used the SkypeIn/SkypeOut services before, then you already know the quality of the calling. So far I have not had any issues with the call quality or dropped calls once the kinks were worked out. While Skype is supporting the freely available G711 codec via its SIP gateways, it is dependent on what codecs are supported by the carrier that is being used to terminate a particular call. So while on SkypeOut I was able to use the G711 codec to terminate to numbers in the San Francisco Bay Area (415/650), on SkypeIn to a San Jose number (408) the only available codec was g729. So the reality is, you will need to have a SIP endpoint that supports the licensed G729 codec for reliable use. The current calls are not encrypted. Skype has already stated they intend to support TLS/SRTP in the near future as encryption is considered a core feature for SIP as much as for their P2P calls. As time permits I will be continuing to do more tests as well as contrasting with the Skype for Asterisk (SfA) beta software. Skype is definitely on the right track by opening their network to key standards with multiple interfacing options. I believe Skype is now poised to become a key global player in the business VoIP market, as well as bringing in a broader range of developers. I began to think this day would never come, but it has...
Posted
 

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
 

Skype for Asterisk component for Adhearsion

After having more time to work in detail with the Skype for Asterisk (SFA) channel in closed beta, I have developed an Adhearsion component to ease my development and testing efforts. Hopefully this will ease yours in the near future when the public beta becomes available.
Media_httpjsgoeckefil_fcqix
The Skype Utils component provides a few features to take advantage of what this new channel brings to the Asterisk platform. First, the component provides a single method call to access a wealth of information in your dialplan that is delivered with each Skype call. This type of information is unheard of on any other channel available to Asterisk (let alone telecoms in general), this information includes:
  • skype_languages - A space-separated list of language identifiers (ie - es, en, etc)
  • skype_topic - A user-provided string that can identify the 'topic' of the call
  • skype_token - Similar to skype_topic
  • skype_about - 'about' profile entry
  • skype_birthday - Birthday
  • skype_gender - Gender
  • skype_homepage - Home page URL
  • skype_homephone - Home phone number
  • skype_officephone - Office phone number
  • skype_mobilephone - Mobile phone number
  • skype_city - City name
  • skype_province - State/Province name
  • skype_country - Country name
The next feature that the component provides is the ability to map Skype usernames with Asterisk extensions. Typically Asterisk is used with phones that require you to enter a numeric phone number when dialing someone. Of course most Skype names are usernames that have nothing to do with a phone number. With this component you may enter the relationship between an extension number and a Skype username in  database with a Ruby on Rails web interface. Then when calls are made to and from the Skype network you have a seamless translation between the two.
Media_httpjsgoeckefil_faoba
Last (so far), but not least, is the ability to track Skype presence information. The SFA channel allows you to add 'buddies' to your Asterisk/Skype username. Once this has been done, you are then able to obtain status updates from each of the buddies on your list. The component then allows you to track these status updates and access them in your dialplan. The status updates may be persisted to a database or kept in memory. Further, those status updates are not only available to your dialplan but to the REST, DRb and STOMP APIs of Adhearsion, making them available to virtually any program. With this you may track if each Skype user is in one of the following states:
  • Online - user is online
  • Skype Me - user is available and asking to be 'Skyped'
  • Away - the user is away from their Skype client
  • Not Available - the user is not available for a call
  • Do Not Disturb - the user does not want to be disturbed
  • Offline (Voicemail Enabled) - the user is offline and has voicemail
  • Offline (Voicemail Disabled) - the user is offline and has no voicemail
Stay tuned for example applications that will build upon this component. In the meantime do not hesitate to have a look at the code and details here. I would also like to thank @steely_glint and Todd Gould, fellow beta team members, for their assistance in constructing an environment where all the pieces could work. Great progress is being made on the SFA beta code, but of course there are still some quirks.
Posted