Bluetooth 3.0 arrives

The Bluetooth 3.0 specification has finally been ratified.

The main new feature is the Alternate MAC/PHY (AMP), that lets Bluetooth piggyback on Wi-Fi for high speed data transfers. The way it works is that applications write to the traditional Bluetooth Profile APIs, and connections are negotiated using the traditional Bluetooth radio. But then for high-speed data transfers the system switches to a direct peer-to-peer Wi-Fi session. This enables things like bulk syncing of photos from your phone to your PC, or streaming uncompressed CD stereo audio to wireless loudspeakers.

I wrote about Bluetooth AMP before, wondering why it retained a dependency on Bluetooth radio. The answer is that in idle, listening mode waiting for activity, Bluetooth is more power efficient than Wi-Fi, while Wi-Fi is more power efficient for bulk data transfers. This makes Bluetooth’s other next big thing, LE (formerly Wibree), an interesting complement to AMP: for power efficiency Bluetooth devices will reside in two modes, very low power idle mode (LE), and Wi-Fi mode when transferring data.

The Bluetooth 3.0 specification talks about 802.11 rather than 11g or 11n, since 802.11n is not yet ratified, but some of the companies involved will be supporting draft 802.11n anyway.

From an industry point of view there are several interesting aspects to this announcement, among them:

  • Atheros’ ascendence. Atheros, a leader in Wi-Fi, only recently got into the Bluetooth market, and currently only plays in the PC Bluetooth market. It dabbled in headset Bluetooth and got out, and has not yet announced Bluetooth for handsets. So Atheros is a minor player in Bluetooth, eclipsed by CSR and Broadcom, and several others. But Kevin Hayes of Atheros was the technical editor for the 802.11 Protocol Adaptation Layer of the Bluetooth 3.0 specification, and Atheros supplied the video and the demo of AMP at the 3.0 announcement event.
  • Potential movement of Wi-Fi into feature phones. Handset makers slice the market into four main segments: ultra low cost phones, basic phones, feature phones and smart phones. Wi-Fi is now pretty much ubiquitous in new smartphones, but effectively absent in all other types of cell phone. But feature phones have music and cameras which generate exactly the data that Bluetooth 3.0 was designed to sync with PCs, so Bluetooth 3.0 provides a motivation to handset manufacturers to add Wi-Fi to their feature phones. This will vastly boost the Wi-Fi attach rate in 2010 and beyond.
  • Another nail in the coffin of UWB (Ultra Wide-Band). In its original conception, AMP was to use WiMedia’s flavor of UWB. Later Wi-Fi was added to the mix, and now UWB is absent from the spec. UWB has so far failed to meet its performance expectations, and rather than fix it the WiMedia Alliance threw in the towel in March 2009. I suppose it is possible that the few companies still toiling away on fixing UWB will eventually overcome its performance woes, and that it will get adopted into the Bluetooth specification.

Open up Skype?

Skype is the gorilla of HD Voice. Looking at my Skype client I see that there are at this moment about 16 million people enjoying the wideband audio experience on Skype. The other main type of Voice over IP, SIP, is rarely used for HD Voice conversations, though I wrote an HD Voice Cookbook to help to popularize wideband codecs on SIP. Since Skype has the largest base of wideband codec users, those who are enthusiasts of both HD Voice and SIP are eager for SIP networks to interoperate with Skype, allowing all HD-capable endpoints to talk HD to each other. Skype does already kind of interoperate with SIP, but only through the PSTN, which reduces the wideband media stream to narrowband. Opening up Skype would solve this problem, so it’s obviously a good idea. What is not so clear, however, is what it means to “open up Skype.”

Skype reinvented Voice over IP, and did it better than SIP. SIP was originally intended to be a lightweight way to set up real-time communications session. It was the Internet Engineering Task Force’s response to the complexities of the ITU VoIP standard, H.323. But SIP got hijacked by the telephone industry, and recast into the familiar mold of proliferating standards and proprietary implementations. SIP is no longer lightweight, implementation is a challenge and only the basic features are easily interoperable.

Take a look at my HD Voice Cookbook to see what it takes to set up a typical SIP phone, then compare this to installing Skype on your PC. Or compare it to the simplicity of plugging in a POTS phone to your wall socket. So we have:

  • Skype, free video calls with HD voice from your PC to anywhere in the world;
  • POTS, narrowband voice-only calls that cost about $30 per month plus per-minute charges for international calls; or
  • SIP, that falls somewhere in between the two but which is way too complex for consumers to set up, and which people only really use for narrowband because everybody else only uses it for narrowband, so there’s no network effect.

Open VoIP standards got a several-year start on Skype, starting with H.323 and going on to SIP; but from its inception Skype blew them out of the water. To be sure it had a strong hype amplifier since P2P file sharing was controversial at that time, and Skype came from the same people as Kazaa, but at that time NetMeeting (an H.323 VoIP program) had an enormous installed base, since it came as part of Windows. The problem Skype solved was ease of use.

Skype doesn’t just give you video and wideband voice. It’s all encrypted and you get all sorts of bonus features like conferencing, presence, chat, desktop sharing, NAT traversal and dial-by-name. And did I mention it’s free?

The open standards VoIP community was beaten fair and square by Skype, blowing a several year start in the process.

Let me clarify that. In terms of minutes of voice traffic on network backbones, SIP traffic outweighs Skype, so from that point of view, SIP is not so beaten by Skype. The sense in which Skype has trounced the open standards VoIP community is in providing users with something better and cheaper than the decades-old PSTN experience, which carrier VoIP merely strives to emulate at a marginally lower price.

So it seems to me like sour grapes to clamor for Skype to make technical changes to conform to open standards, especially if those changes would impair some of the benefits that Skype offers users. How would users benefit from opening up Skype? Would the competition lower the cost of a Skype call? It’s hard to see how, when Skype calls are free. Would the service be more accessible, or accessible to more customers? No, because anybody with a browser can download Skype free by typing “Skype” or even “Skipe” into their browser’s search field. Would the open standards community innovate faster than Skype, and provide more and better features? Not based on the their respective track records. The open standards community has had plenty of time to out-innovate Skype and manifestly failed.

Anyway, what are the senses in which Skype is not open? It is certainly interoperable with the PSTN; SkypeIn and SkypeOut are among the cheapest ways to make calls on the PSTN. Actually, this may be the greatest threat to Skype’s innovation. SkypeIn and SkypeOut are the only way that Skype makes money; this is a powerful motivation for Skype to not incent users to abandon them. If this remains the only economic force acting on the company Skype is likely to decay into an old-style regular phone service provider.

After a lot of debate with people who know about these things, there seem to be two main ways in which Skype could be said to be not open:

  1. The protocol is proprietary and not published, so third parties can’t implement endpoints that interoperate with Skype endpoints.
  2. Only Skype can issue Skype addresses, and Skype controls the directories rather than using DNS like SIP.

Let’s look at the issue of the proprietary protocol first. Let’s break it into two parts, first who defines the protocols and second, their secrecy. In the debate between the cathedral and the bazaar, the cathedral has recently been losing out to the bazaar amongst the theorizers. We see the success of Apache, MySQL, Linux and Firefox and it looks as though the cathedral is being routed in the marketplace, too. But on the other hand we have successful companies like Apple, Google, Intel and Skype, whose success demonstrates that a design monopoly can often deliver a more elegant and tight user experience. There is no Linus Torvalds of SIP. Having taken the decision to implement a protocol other than SIP, it seems fine to me that whoever invented the Skype protocol should continue to design it, especially since they have manifestly done a much better job than the designers of SIP – ‘better’ in the sense of being more appealing to users.

What about the secrecy? A while back one of the original designers of SIP, Henning Schulzrinne, with his colleague Salman Baset, reverse engineered the Skype network and published his findings here. There is more technical background on Skype here. According to Baset and Schulzrinne:

Login is perhaps the most critical function to the Skype operation. It is during this process a Skype client authenticates its user name and password with the login server, advertises its presence to other peers and its buddies, determines the type of NAT and firewall it is behind, discovers online Skype nodes with public IP addresses, and checks the availability of latest Skype version.

Opening up the protocol to let other people use it would enable them to implement their own Skype login servers. This would enable a parallel network, but in the absence of a new protocol that enabled the login servers to exchange information, it would not lead to interoperability, in the sense of users on Skype being able to view the presence information of users on the parallel network, or even retrieve their IP address to make a call. So it would have the effect of fragmenting the Skype network, rather than opening it. Alternatively the Skype login servers could implement the SIP protocol to exchange presence information. But then it would start to be a SIP network, not a Skype network. And the market numbers say that users find SIP inferior to Skype. So why do it?

Opening up the protocol to let other people write Skype clients that logged into the Skype login servers would open up the network, but at the risk of introducing interoperability issues due to faulty interpretations of the specification. Network protocols are notoriously prone to this kind of problem. But guaranteed interoperability of the clients is one of the primary benefits of Skype over SIP from the point of view of the user, who would therefore not benefit from this step.

So why not have Skype distribute binaries that expose to third party applications the functionality of the protocols and the ability to log into the Skype login server through a published API? Wait a sec – they already do that.

Another objection to Skype publishing the protocols for third parties to implement is that there would be a danger of the third parties implementing some parts of the protocol but not others. For example not the encryption part, or not the parts that enable clients to be super-nodes or relays. A proliferation of this kind of free-rider would stress the network, making it more prone to failure.

Related to the issue of who implements the login servers is who issues Skype addresses. There is a central authority for issuing phone numbers (the ITU), and a central authority for issuing IP addresses (the IANA). But in both cases, the address space is hierarchical, allowing the central authority to delegate blocks of addresses to third party issuers. The Skype address space is not hierarchical, so it would require some kind of reworking to enable delegation. Alternatively the Skype login servers could accept logins from anybody with a SIP address. But there would be no guarantee that the client logging in was interoperable.

Scanning back through this posting, I see that my arguments could be parodied as “you can’t argue with success,” and “if it ain’t broke don’t fix it.” Arguments of this type are normally weak, so in this case I think my points are actually “there are reasons for Skype’s success,” “fixes could break it,” and “users would be better served if Skype competitors concentrated on seducing them with a superior offering,” the last of which, after all, is how Skype has won its users away from the traditional telecom industry. Some people are trying this approach, notably Gizmo5, which I plan to write about later.

HD Voice Cookbook

One of the themes of this blog is how phone conversations can sound much better in VoIP because of wideband codecs. If you have a corporate IT department and a new PBX from a company like Cisco, Avaya, Nortel, Siemens or Alcatel-Lucent, the phones can normally can be configured to use the (wideband) G.722 codec on internal calls. And if you use Skype on your PC, it normally runs with a wideband codec, unless you make a SkypeOut call to a regular phone number.

But what if you are working out of a home office, and you just want your desk phone to sound good, and to use a wideband codec when calling other phones with wideband capabilities? Unfortunately its still a project that can require some technical skills and a lot of time. To make it easier for you, here’s a cookbook explaining step by step how I did it for a particular implementation (Polycom IP650 phone using an account at OnSIP).

Skype for iPhone

Well, that last post on the likely deficiencies of VoIP on iPhones may turn out to have been overly pessimistic. It looks as though Hell is beginning to freeze over. Skype is now running on iPhones over the Wi-Fi connection, and for a new release it’s running relatively well. AT&T deserves props for letting it happen – unlike T-Mobile, which isn’t letting it happen and therefore deserves whatever the opposite of props is.

6 hours after it was released Skype became the highest-volume download on Apple’s AppStore. In keeping with Skype’s reputation for ease of use, it downloads and installs with no problems, though as one expects with first revisions it has some bugs.

My brief experience with it has included several crashes – twice when I hung up a call and once when a calendar alarm went off in the middle of a call. Another interesting quirk is that when I called a friend on a PC Skype client from my iPhone, I heard him answer twice, about 3 seconds apart. Presumably a revision will be out soon to fix these problems.

Other quirky behaviour is a by-product of the iPhone architecture rather than bugs, and will have to be fixed with changes to the way the iPhone works. The biggest issue of this kind is that it is relatively hard to receive calls, since the Skype application has to be running in the foreground to receive a call. This is because the iPhone architecture preserves battery life by not allowing programs to run in the background.

Similar system design characteristics mean that when a cellular call comes in a Skype call in progress is instantly bumped off rather than offering the usual call waiting options. I couldn’t get my Bluetooth headset to work with Skype, so either it can’t be done, or the method to do it doesn’t reach Skype’s exemplary ease of use standards.

Now for the good news. It’s free. It’s free to call from anywhere in the world to anywhere in the world. And the sound quality is very good for a cell phone, even though the codec is only G.729. I expect future revisions to add SILK wideband audio support to deliver sound quality better than anything ever heard on a cell phone before. The chat works beautifully, and it is synchronized with the chat window on your PC, so everything typed by either party appears on both your iPhone and PC screen, with less than a second of lag.

After a half-hour Skype to Skype conversation on the iPhone I looked at my AT&T bill. No voice minutes and no data minutes had been charged, so there appear to be no gotchas in that department. A friend used an iPod Touch to make Skype Wi-Fi calls from an airport hot-spot in Germany – he reports the call quality was fine.

The New York Times review is here