Technology, Thoughts & Trinkets

Touring the digital through type

Some Data on the Skype iPhone Application

SkypePhoneSkype is a polarizing product for telecom operators and customers. It is an application that lets customers abandon their historical phone services in favour of an encrypted Voice over Internet Protocol (VoIP) communications service that provides ‘free’ calls to computers and cheap rates when making a Skype-to-analogue/cellular phone service. For customers, it extends the choices presented to them and potentially reduces their monthly phone expenses.

The iPhone application for Skype has made headlines as telecom and smartphone manufacturers alike have actively and passively resisted, and ultimately relented, to permitting customers make Skype calls from their iPhones and other mobile devices. Apple has stated that they will not ‘jump through hoops’ to ensure that VoIP applications work through successive operating system updates, and AT&T’s poor data transmission systems likely made them somewhat hesitant to allow another bandwidth-heavy service onto their networks. What really got *me* interested in the Skype iPhone application, as a Canadian, was the following:

  1. Canadian customers can now install Skype on their iPhones;
  2. There was no place on the web that informed Skype users of how much data was consumed by the iPhone application when in use.

It was #2 that was particularly interesting. Canadian consumers tend to have fairly low default bandwidth caps with Rogers, the primary carrier of the iPhone in Canada, at 1GB in the basic iPhone plan. My thought was this: if the iPhone application actually consumed massive amounts of data Rogers would:

  1. Make a killing on the likely data overages as early adopters shifted over to Skype VoIP in favour of Rogers’ own voice services;
  2. If the application actually consumed a large amount of bandwidth, carriers might see it as ‘technically’ needing to be mediated using some system (perhaps deep packet inspection).

I started putting out feelers, and no one knew how much data the application consumed. Rogers claimed they didn’t know, nor did Apple. A contact on Twitter who worked as customer relations for Skype also doesn’t know the amount of data used, and the information was nowhere (that I could find) on the English-written web. Similarly, my international contacts were uncertain about data requirements. Fortunately, after an extended wait, I’ve finally received word from Skype’s customer service desks (my last ditch effort was to submit a support ticket). Here is how the relevant part of the email reads:

In a call Skype uses between 3-16 kilobytes/sec depending on bandwidth available for other party, network conditions in between, callers CPU performance, etc.

On average Skype uses 0-0.5 kilobytes/sec while idle. This is used mainly for contact presence updates.

From this, if we assume that around 300MB of iPhone data usage is for non-Skype traffic (based on Gillian Shaw’s account that most Rogers users consume less than 500MB of data), then someone using Skype might use the remainder of their data plan to ‘talk’ using Skype for up to 724 minutes (based on 16.5KB/s being used constantly when the application is running; more talk time is probable, if we assume that the application will not constantly use 16.5 GB/s). Given that it only costs $2.95/month to have Skype-Canadian landline calling, this means that for for just a little extra money on top of the regular iPhone plans you can get a whole lot more ‘minutes’ than normally provided through Rogers, though roaming data charges will apply if you leave your local zone.

Given that you can switch over to wireless networks rather than use the 3G network when possible, Skype moving to mobile environments has the potential to readjust how wireless providers function, just as MCI changed how long distance functioned in the United States. With this potential in mind, issues of network neutrality become particularly important, as does the need for genuine transparency in the capabilities of data networks. In the US, we see AT&T struggling to provide data services across their network but we are also lacking real information on their data haul abilities. Now, where the FCC is asserting that network neutrality must apply to both mobile and wireline data networks in Canada we are seeing the carriers insist that the CRTC avoids regulating how ISPs can mediate wireless traffic using DPI appliances.

Will the CRTC remain relatively conservative, and avoid committing to network neutrality principles similar to the FCC, and wait for a complaint against ISPs regulating mobile data usage, or will it take a stand and maintain that principles they develop concerning DPI should apply to both wireless and wireline data transmissions? If Skype is identified as a ‘problem application’ by Rogers on the basis of its data usage consumption, would they be motivated to mediate wireless traffic as they do wireline traffic?


  1. Skype is one of those weird ones. Actually, its fair to say its THE weird one.

    I’ve used Skype as an example protocol in my DPI discussions, but I was being a bit disingenuous. At this time, there is no DPI or security appliance that can reliably detect a Skype VOIP call. It has no signature that can be detected by management appliances.

    So far (according to the sources I have, and from personal experience) appliances that claim they can block Skype are not 100% accurate. Hell, they’re not even close. Generally speaking, they only block the Skype software when they detect it is trying to download an update to the client.

    • Allot Communications produced a whitepaper a while back (2007?) that talked about techniques of blocking applications like Skype – their method (at the time) was to identify the initial packets in a packet stream; as soon as a particular set of packets, which corresponded with particular packet sizes, was detected you could be pretty certain that it was a Skype call that was being made. I assumed that this, or a similar, technique would continue to be effective based on a presentation from a UoT computer scientist who suggest that it still should be – should I rid myself of this assumption?

  2. I dunno to be honest. I have a hard time accepting that Skype is so difficult to identify from other traffic.

    But the 3 types of DPI capable appliances I have sure as heck can’t block it. Is this a permanent state of affairs? I can’t commit to that.

  3. I’ve had the various techniques that Skype uses to obfuscate its traffic laid out to me before, and it’s clever (and changes with every update to the application). This said, all obfuscation can be defeated – it usually takes DPI vendors a bit, but they can identify it again shortly after an update just be virtualizing a closed network environment and watching data move between skype applications on virtual node computers.

    This said, I’ve gotten this from mid-high level discussions, rather than through an engineer walking me through the process (which suggests there has to be some pretty substantial abstraction going on)…

  4. I just pinged my security white guys, and at the moment they would recommend Palo Alto networks as a vendor that is best at identifying Skype.

    BlueCoat has a nice how-to on blocking Skype. But from what I’m reading, it is easier to block Skype (and related protocols such as non-HTTP conforming Port 80 use) than it is to shape it. The most effective techniques look at what the traffic isn’t, rather than what it is. Due to the proprietary encryption used, the certainty required to shape that traffic and apply policies is not there. The techniques described are hazy enough that their use would affect other applications as well.

    On a private corporate network, this isn’t that big a deal. On the public space? Ugh.

  5. Il est enfin temps que Skype iclue la 3G pour l iPhone.

    • Oui, il est. L’information dans le poteau est au-dessus du wifi, pas 3G. Je ne sais pas s’il y a de compression additionnelle sur 3G. (traduit utilisant Babelfish)

Leave a Reply

Your email address will not be published.