Speaking of Standards

Want to implement Skype’s SILK super wideband audio codec? You know, the software that makes Skype’s audio calls sound so rich and like you are “right there”?

If so, just check out Appendix A of this massive Internet-Draft:

http://tools.ietf.org/html/draft-vos-silk

Coming in at 566 pages, this I-D is what the word “ginormous” was meant for… but if you look closer, you’ll see that the first 26 pages describe the SILK codec and provide the usual IETF language. The remaining 540 pages are the C source code for a reference implementation of SILK!

This is part of the work of the IETF’s “CODEC Working Group” (see “MOVING INTO THE IETF” below) to standardize on a new wideband audio codec and essentially upgrade the audio quality of the Internet. Let me lay out some background…

---

LAUNCHING SILK

Last year at eComm 2009, Skype’s Jonathan Christensen announced the SILK codec and that it was being released for free licensing to third-party software and hard developers. Skype made available a developer site focused on the codec:

https://developer.skype.com/silk

Christensen trumpeted these items as the strengths of SILK:

• improving audio bandwidth going from 8 kHz to 12 kHz, meaning that a SILK conversation sounds like you are in the same room as the person you are speaking with
• providing real-time bandwidth scalability to deal with degraded network conditions
• balancing codec optimization between voice, music and background noise, each of which can have an impact on the overall user experience
• delivering a robust solution that delivers a more consistent audio experience, regardless of network conditions and an individual user’s voice signature

You can watch his eComm announcement here:

or view his slides here:

As a heavy user of Skype, I can personally attest to the fact that the SILK codec, available in all the latest versions of Skype, really does provide an outstanding audio experience.

---

MOVING INTO THE IETF

With the SILK codec available, folks at Skype started to look at how the codec could be made an open standard so that more folks would implement it. In May 2009, Skype’s Jason Fischl started a discussion around forming a new IETF working group to produce a standardized wideband audio codec. Much discussion and several meetings followed that did lead to the creation of the CODEC Working Group within the IETF. The group, created in January 2010 and co-chaired by Peter Saint-Andre and Michael Knappe, is open to the public – anyone can join the mailing list – and the problem statement is very clear:

According to reports from developers of Internet audio applications and operators of Internet audio services, there are no standardized, high-quality audio codecs that meet all of the following three conditions:

1. Are optimized for use in interactive Internet applications.

2. Are published by a recognized standards development organization (SDO) and therefore subject to clear change control.

3. Can be widely implemented and easily distributed among application developers, service operators, and end users.

There exist codecs that provide high quality encoding of audio information, but that are not optimized for the actual conditions of the Internet; according to reports, this mismatch between design and deployment has hindered adoption of such codecs in interactive Internet applications.

There exist codecs that can be widely implemented and easily distributed, but that are not standardized through any SDO; according to reports, this lack of standardization and clear change control has hindered adoption of such codecs in interactive Internet applications.

There exist codecs that are standardized, but that cannot be widely implemented and easily distributed; according to reports, the presence of various usage restrictions (e.g., in the form of requirements to pay royalty fees, obtain a license, enter into a business agreement, or meet other special conditions imposed by a patent holder) has hindered adoptions of such codecs in interactive Internet applications.

According to application developers and service operators, an audio codec that meets all three of these would: (1) enable protocol designers to more easily specify a mandatory-to-implement codec in their protocols and thus improve interoperability; (2) enable developers to more easily easily build innovative, interactive applications for the Internet; (3) enable service operators to more easily deploy affordable, high-quality audio services on the Internet; and (4) enable end users of Internet applications and services to enjoy an improved user experience.

Now, here is a critical point:

The CODEC Working Group is *NOT* just about Skype’s SILK codec!

The CODEC WG is working to identify and standardize a wideband audio codec that could be widely used over the Internet. Skype’s SILK codec is one of the potential codec candidates, as shown on this matrix of codecs from the CODEC WG. Another strong contender is the CELT codec from the Xiph.org team. There is a Internet-Draft out now for discussion that specifies the requirements for a standardized codec:

http://tools.ietf.org/html/draft-ietf-codec-requirements

The goal of the CODEC WG is to either identify an existing codec that meets those requirements or create a new codec. Either way, the goal is to have a standardized high quality audio codec that we can all use.

For those interested, the CODEC working group will be holding its first official face-to-face meeting at IETF 77 in Ananheim, California, on March 22nd. A draft agenda has been posted.

---

SKYPE’S SILK SOURCE CODE

So back on Monday, March 8, a new version of the SILK Internet-Draft was published and announced on the codec mailing list. As the draft notes:

The source code for the reference implementation of the SILK codec is provided in Appendix A. This fixed-point source code is the normative specification of the codec. The corresponding text description in this document is provided for informative purposes. For more information about SILK, the patent licensing terms, and to download the source code in a convenient format, please visit [silk-website]. For any additional questions, please send an email to SILKSupport@skype.net.

This particular phrase is interesting and amusing to me:

This fixed-point source code is the normative specification of the codec.

I translate that as “the source code is the specification”.

If you do read the source code, you see Skype’s license on the code is rather open:

Copyright (c) 2006-2010, Skype Limited. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, (subject to the limitations in the disclaimer below)
are permitted provided that the following conditions are met:
- Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
- Neither the name of Skype Limited, nor the names of specific
contributors, may be used to endorse or promote products derived from
this software without specific prior written permission.
NO EXPRESS OR IMPLIED LICENSES TO ANY PARTY'S PATENT RIGHTS ARE GRANTED
BY THIS LICENSE.THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS ''AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Essentially it is a Skype version of the permissive “Simplified BSD License“, which I would summarize as a non-lawyer as essentially “keep the copyrights intact, don’t use Skype’s name for endorsement, and Skype is in no way responsible if bad things happen from using this code”.

Still to be seen is if there are any additional licensing terms from Skype, but overall this is a great step forward for those of us who want to see better overall audio quality on the Internet. Obviously it’s in Skype’s interest to do this so that the CODEC WG might consider SILK as the codec to standardize on versus the others or creating a new one… but still… it’s great to see. What do you all think?

NOTE: David Bryan, co-chair of the IETF’s P2PSIP Working Group, left this text as a comment to my earlier post about P2PSIP and Skype. Given it’s length and great content, I thought it should run as a guest post and David was fine with that. The text below is entirely his.

---

So a few points, in no particular order:

Lee mentioned (as have others before) that P2PSIP is “copy-cat Skype”. This always bothers me, not because we came first (we certainly didn’t) but because it wasn’t my vision for P2PSIP (although others certainly had that view) . When I came up with P2PSIP and brought it to the IETF, I wanted to do things SIP couldn’t do at all. SIP can theoretically build a system that looks like Skype. To me, the interesting areas for P2PSIP were distributed softswitches/corporate IM (config-free small office, etc.), rapid response (quickly set up a communications system after a natural disaster), ad-hoc clusters for IM/app sharing (think Google wave away from the Internet), and vendors adding voice to apps without becoming an ISP. You could do a Skype-like service with P2PSIP (sort of: see below) but that wasn’t really the idea that got me started creating P2PSIP.

To me, Skype’s success was solving the NAT issue and getting the user experience right. P2P was a means to an end/efficiency multiplier, but not the reason for the success. Skype just worked. SIP’s major flaw is embedded IP addresses. Skype avoids this, uses media relays (P2P, but could have been centralized) and “falls back” (in the worst case) to tunneling over port 80. Users love this. Administrators and protocol purists hate it as it breaks traffic characterization, shaping, etc. Skype’s closed garden (one protocol stack) also ensured things just worked. Closed gardens and HTTP tunnels are at odds with the SIP goal of vendor/carrier interoperability. The two achieve different goals. (Today, many folks believe ICE with ISP-provided relays has addressed the SIP NAT problem. It looks promising, but until we have a Skype-sized Internet deployment, some say the jury is out. Time will tell.)

You could theoretically deliver a Skype-like experience with either a SIP or P2PSIP solution. Pure P2PSIP is very decentralized (every node is a peer and central servers are only used for obtaining a certificate), so you would need a hybrid approach if you want to maintain customer control. You could also use regular SIP with ICE, and many, many servers if you could solve the scalability problems. The best approach might be conventional SIP between the endpoints and a cloud of servers, with the servers sharing information using P2P. This ends up looking much like a SIP version of Skype’s super-peer model, executed in the cloud.

All this still begs the question of what happens to the Skype ecosystem of hardware, etc. If you go SIP, what do you break in the process? As Dan York and Shidan Gouran point out, Skype has many options, lots of great engineers, and lots of cash, but nobody outside of Skype knows what they will do.

As an aside to Lee’s comment on P2PSIP as a standard (it is fair to say adoption in product has been very slow, I’m sorry to say): The standard is moving, just at the (glacial) pace of standards, which can be frustrating for idea guys like Lee or I. In the early days, P2PSIP had lots of ideas, chatter, and excited non-standards folks, so work moved quickly. Today, with an accepted draft in progress and a more mainstream standards audience, iterations have slowed. That said, things are moving, there is strong interest, and a lot of hard work by the editors and participants.

My biggest worry is the protocol becoming too cumbersome. We are building a very flexible, universal DHT protocol with mandatory ICE and TLS/DTLS security. This is great for some scenarios, but overkill for others (ad-hoc, for example), and I worry the bulk may make it unsuitable for some of the scenarios I first imagined. I think many of these may migrate to the cloud. DHTs will be used, but as a means to distribute data among servers, not all the way to the edge as I first anticipated. Things change. Progress is good. I’m very excited to see how DHT principals in the cloud might solve many of the problems posed of a pure P2P approach. (eComm talk for SF, Lee?)

---

David Bryan is co-chair of the IETF P2PSIP Working Group and maintainer of http://www.p2psip.org/ More about David can be found at http://www.ethernot.org/ or on Twitter at @davidbryan.

---

Last November, Skype announced that they were seeking a someone to head up the Skype Developer Community program. I wrote about this over on my DisruptiveTelephony blog and Jim Courtney wrote a more detailed piece on his Voice on the Web site. Jim quoted – and agreed with – my statement:

For those of us watching the emerging communication/telephony space, we’ve seen Skype make several different attempts over the years to create a successful developer program. Given their incredible user base and platform, it’s been curious to see that they haven’t yet found the right formula.

Skype has tried several times to create a strong developer program. In fact, we here at Voxeo were part of one of the first early attempts, their “Voice Services” program back in 2005 which eventually faded away. We still are huge fans of Skype, use it heavily internally and are very pleased that we are able to provide inbound Skype connections to voice applications on our platform. We want Skype to succeed.

So I was immensely pleased when, a bit over a month ago, Skype announced that they were hiring CounterPath CTO Jason Fischl as their Director of Developer Relations to head up their Developer Program, among other tasks. Through my work in the IETF and meeting at various events, Jason and I have become friends and so I was personally thrilled for him to step into this role. He is a smart guy with great communication skills. His work as CTO of CounterPath, arguably the largest provider of softphones out there (probably mostly known for X-Lite, but producer of many others), has given him a great view into softphone technology. And through all that, he has a wealth of connections into the developer community. Hiring Jason was a great move on Skype’s part.

What is interesting to look at from a standards point-of-view, though, is that in the hiring of Jason, Skype also imported some solid and current SIP-related credentials. Jason has been very active in the real-time communication area of the IETF – the area that deals with the SIP protocol – and has been involved in many of the IETF working groups in the area.

In fact, he is currently one of the co-chairs of the Basic Level of Interoperability for SIP Services (BLISS) Working Group whose aim it is to facilitate basic interoperability between SIP endpoints (hardphones, softphones, etc.). Primarily BLISS is aiming to solve the issue that SIP allows multiple ways to do things (such as signal “Do Not Disturb”) and different vendors have implemented different mechanisms. BLISS is trying to help make the interop cleaner. The working group is also where some cool new work like a RESTful API for automated call handling is being developed.

Jason is also the lead author on the Internet-Draft about using Secure RTP over DTLS, which has been identified as “the way forward” for establishing secure, encrypted media sessions between SIP endpoints to replace today’s reliance on ‘sdescriptions’. (After a lengthy series of meetings/discussions and something like 13 other proposals including Phil Zimmermann’s ZRTP.) Assuming Jason continues his IETF work and this document proceeds to becoming an RFC, there will be an amusing bit of irony to have the IETF’s main method for secure media co-authored by someone at the proprietary Skype. (Although in truth Skype has a huge SIP backend infrastructure for PSTN connectivity.)

Jason is also the editor of a highly-regarded draft on a certificate management system for SIP and has been involved with a number of other drafts. All in all he’s got very solid SIP credentials and background in open standards and open source. He’s a good guy to have at Skype and I certainly wish him all the best on coming up with Skype’s nth Developer Program. We look forward to seeing how it evolves (and seeing how we can work with the folks at Skype).

Not that I’m setting high expectations or anything… okay, Jason?

---

UPDATE: There’s also an interview with Jason up on YouTube about his new role.

---

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook or following us on Twitter.

---

Technorati Tags: skype, jasonfischl, developers, sip, ietf

Yesterday Skype announced the beta program for “Skype For SIP“, a new service that allows some forms of SIP connectivity between a premise-based SIP server/IP-PBX and Skype’s cloud and the PSTN. Over the weekend I put together a very lengthy post on my external DisruptiveTelephony blog that goes into the service in great detail, but the net of it is that when you sign up for the “Skype For SIP” service, you will be able to:

• Receive inbound calls to your SIP server from Skype users.
• Receive inbound calls to “Online Numbers” (formerly “SkypeIn”) that are routed to your SIP server.
• Place outbound calls to PSTN phone numbers using what was called “SkypeOut” and at Skype’s cheap rates.

The calls from Skype users are free to all involved. The Online Numbers only cost you $60 per year and the outbound calls are at Skype’s various rates.

The program, at www.skypeforsip.com, is accepting applications into the beta program now. Skype isn’t clear on when it will leave beta, but is clear that they will be evolving the program over the next weeks and months.

Note that what you are NOT able to do is to place calls from your SIP server to Skype users. So the interaction with Skype clients is one way – you can receive calls from Skype clients but not call those (at least not yet). As IfByPhone CEO Irv Shapiro notes in his blog post, Skype also has the “Skype For Asterisk” service available in a beta form and it does provide two-way connectivity to Skype users.

From a Voxeo point-of-view, what’s interesting is that this seems to have the potential of providing to users of our premise application platform, Prophecy, a similar kind of inbound Skype connectivity to what we’ve had for about four years now in our hosted application platform (and about which I wrote about last year). According to the info from Skype, Skype users would be able to call into applications by calling a Skype name which would then route the call over SIP to Prophecy. It’s a bit different from our hosted Skype connectivity in that it is a Skype name directing you to the entire platform, whereas in our hosted environment you have a Skype address for each application. Prophecy users would also, it seems, be able to use Skype For SIP to have outbound PSTN connectivity (a.k.a. “SIP trunking”) subject to Skype’s rates.

We’ll have to see how that all shakes out once we can try the software out, but it’s interesting nonetheless. Kudos to Skype for lowering their walls a bit and providing this kind of SIP support.

UPDATE: I also have a video podcast, Emerging Tech Talk #28, up on the subject.

---

If you found this post interesting or helpful, please consider either subscribing via RSS or following on Twitter.

---

Technorati Tags: sip, skype

Over on the EComm2008 blog, Lee Dryburgh posted the transcript of a fascinating interview with Jonathan Christensen, general manager of audio and video at Skype. The interview is well-worth a read as Jonathan provides a preview of his upcoming keynote at EComm 2008 with his view of Internet-based communication and talks about advances they have made at Skype with regard to wideband audio and echo cancellation. I do definitely agree with his statement around the improvements they’ve made with echo cancellation on the Mac. Ever since upgrading to the latest Skype, I’ve made many calls with it from my MacBook Pro without any headset whatsoever and have been told the quality has been excellent (and it has been for me when I’m talking to other headset-free Skype users).

Much more relevant to this blog, though, were Jonathan’s statements regarding SIP. At the beginning Jonathan mentions how he originally got very excited by the vision of SIP and ran around stirring up interest at Microsoft where he worked then. But at the end of the interview, Lee asked Jonathan to elaborate on his earlier comments about SIP. This is what Jonathan said:

Yes, so just one clarification – we use SIP. Where, by comparison to the other operators, we are one of the largest SIP users in the world. All of our SkypeOut minutes and SkypeIn minutes traverse the PSTN via SIP interfaces, basically. So, we use it as an interop protocol where we need to.

I think that the vision of the early SIP founders has been largely unrealunrealized [See comments] in the SIP world. SIP is typically just used for these very mundane trunking applications, like the one that we have, or sending calls between two networks and it’s just calls. The vision of multi-modal communications and rich end points has largely failed within the same. I think that a big part of this is that they didn’t pragmatically just solve basic problems like NAT traversal, for example. They also evolved the specification to the point that it no longer had its lightweight appeal. So, we’ll see, SIP will continue to be [the] dominant protocol in terms of this sort of narrowly defined scenarios but I think that, when it comes to rich communications, you are going to see more of this fragmentation. You’re going to see some islands of providers who are just solving the problems. Just making it work for the user and not being religious about the protocol for example.

Has the vision of rich communication over SIP been “largely unrealized”? What do you think? Are his statements true? Or exaggerated?

FYI, if you are attending EComm 2008 you’ll have a chance to hear Jonathan Christensen’s keynote directly. And if you aren’t yet attending EComm 2008, why not?

P.S. For the record, we, too, are huge users of SIP for our connections to/from the PSTN and also throughout our hosted Evolution platform as well as our on-premise Prophecy product. Developers on our hosted platform also get by default SIP *and* Skype dial-in numbers for their applications.

Technorati Tags: skype, sip, ecomm, ecomm2008, conferences, jonathan christensen

One of the more interesting (to me) working groups within the IETF right now is the “P2PSIP” working group which is aiming to develop ways to let SIP clients communicate on a “peer-to-peer” basis, i.e. without any servers. As stated in the working group’s charter:

The Peer-to-Peer (P2P) Session Initiation Protocol working group (P2PSIP WG) is chartered to develop protocols and mechanisms for the use of the Session Initiation Protocol (SIP) in settings where the service of establishing and managing sessions is principally handled by a collection of intelligent endpoints, rather than centralized servers as in SIP as currently deployed. A number of cases where such an architecture is desirable have been documented.

Peer-to-peer is intriguing to me primarily because it does represent a different deployment paradigm than what we are primarily using today for SIP deployments. Today SIP clients register with SIP servers and all the signaling is generally handled by those servers. With P2PSIP, the idea would be that you remove the servers and have all the routing, signaling, etc. handled by the “cloud” of P2P SIP clients. Clients get added and removed to the P2P cloud as they come and go and all the “intelligence” resides in the cloud.

Outside of the world of open standards, this architecture is best seen in voice with Skype. Skype clients connect to each other and route calls and media packets across the Skype cloud. I should note that Skype is not a pure P2P cloud. As was shown by the 2-day outage earlier this year, Skype still does very much rely on servers for authentication.

Will the P2PSIP working group wind up creating something like an open standards version of Skype? Maybe… maybe not… the effort is really only in the beginning stages. (And you can stay up with what is going on at “p2psip.org“.) There are all sorts of security and privacy issues that have to be addressed but it’s intriguing to see. It’s certainly a group I’ll be monitoring and participating in to the extent that I can.

P.S. If you are curious to experiment with open P2P architectures, you can check out OpenDHT.org, an open, publicly accessbile distributed hash table (DHT). Do be warned, though, that this is really for developers…

Technorati Tags: ietf, sip, skype, p2p, p2psip