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?

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

FYI, a new version -08 of my P-Charge-Info Internet-Draft is now available:

http://www.ietf.org/id/draft-york-sipping-p-charge-info-08.txt

For an understanding of what P-Charge-Info is all about, read why I first wrote it, P-Charge-Info and incredible disconnect between PSTN billing and the new world of SIP, and then my update last year on the -07 draft.

Version -08 really only has a minor tweak to the ABNF notation for the “npi-value” and then a new Appendix A clarifying the npi-values and their relation to ANSI T1.113.

I am hoping that I can very shortly request IESG consideration to move this document along the path to being an RFC. The only remaining issue is that my co-author, Tolga Asveren, has brought forward a proposal for simplifying the parameters a bit. I’ve forwarded that proposal to several people I know are very interested in this draft. We’ll see where it goes from there. I’d very much like to move this along soon, so we’ll see.

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

As a “security guy“, I have been pleased to watch the emergence of the OAuth Working Group within the IETF and the work that is underway to create an actual IETF specification for OAuth. I haven’t had time to participate, but I’m glad to see that work going on.

If you aren’t aware of OAuth, it’s basically a way that you can authorize a application or service to interact with another application or service on your behalf without giving that first application or service your user ID and password for the second service or app.

For example, if you were a Twitter user in its earlier days, every time you wanted to use another application or web service with your Twitter account, you had to give that app or service your Twitter user ID and password. There’s a security issue here in that you are entrusting your credentials to some other company or application – and trusting that they won’t share those credentials. There’s also a configuration issue in that if you change your password you then have to go to all the other services and provide the updated info. Now, with OAuth support in Twitter, when you want to add a new service to interact with your Twitter account, you are prompted to login to your Twitter account and authorize or deny the access for the new service. The key point is that the new service or application never gets your Twitter credentials. (And as another example, OAuth is what our IMified service uses to allow an automated bot to interact with your Twitter account.)

Anyway, OAuth emerged out of the developer community and now there is work underway in the IETF to create official standard specifications to help in promoting OAuth implementation. As a first step, it was announced this week that OAuth 1.0 will be published as an Informational RFC. As noted in the announcement:

The OAuth protocol was originally created by a small community of web developers from a variety of websites and other Internet services, who wanted to solve the common problem of enabling delegated access to protected resources. The resulting OAuth protocol was stabilized at version 1.0 in October 2007, and revised in June 2009 (revision A) as

published at <http://oauth.net/core/1.0a>.

This specification provides an informational documentation of OAuth Core 1.0 Revision A, addressing several errata reported since that time,

as well as numerous editorial clarifications. While this specification is not an item of the IETF’s OAuth Working Group, which at the time of writing is working on an OAuth version that can be appropriate for publication on the standards track, it has been transferred to the IETF for change control by authors of the original work.

This first step will get a base level spec out so that people looking to implement OAuth will have an IETF specification they can use. The RFC hasn’t been published yet, but the draft that will be an RFC is here:

http://tools.ietf.org/html/draft-hammer-oauth

It’s good to see this work going on within the IETF and I look forward to seeing further work there. From my perspective, OAuth is a great step in helping secure connections betweens apps and services over the web… which is good for all of us as more and more moves into the cloud.

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

Registration for the 77th meeting of the Internet Engineering Task Force (IETF) is now open. The IETF 77 event will take place March 21-26 in Anaheim, California (home of Disneyland).

Sadly, it looks like I personally will be missing this IETF meeting as I’ll be across the continent in the other home of Disney, Orlando, for VoiceCon Orlando 2010. I somehow don’t think the cross-country travel will work that week. The good news, though, is that the timezone will be such that I will be able to participate remotely. Remote participation wasn’t really an option for me with the recent IETF 76 in Japan.

One interesting point in the email announcement was that the IETF is offering essentially a “day pass” again for people who either want to just see what IETF is all about or who only care about sessions happening on a particular day. Per the email, for $200 you get:

1. Attend all sessions during any one day of the Meeting, and partake of the food and beverage during the breaks
2. You select which day to attend when you show up onsite to check-in
3. Payments may be made onsite without a late fee
4. Pass can be upgraded to a full Meeting Registration, however, late fee may apply if initial one-day payment not made before Early Bird deadline
5. Attend Sunday Tutorials at no additional charge
6. Attend Sunday Welcome Reception at no additional charge
7. Attend Wednesday and Thursday Plenaries at no additional charge

Seems like a nice option if all you just want to go to a day of sessions.

In any event, more information and the registration form can be found in links from the IETF 77 meeting page.

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

So what Twitter accounts are out there that write mostly about industry standards?

Thus far I’ve found:

@rfc
@w3c

I’ve added both to a new Twitter List to which you can subscribe, if you like, at:

http://twitter.com/voxeo/standards

If you know of other accounts, please let me know. (Thanks!) There is an @ietf account out there, but it’s only had one tweet back in November 2008.

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

The IETF today made a fairly major announcement:

The IAOC is pleased to announce the ancient and historic city of Beijing as the site for IETF 79 from 7 – 12 November 2010. This will be the IETF’s first meeting in China. The meeting will be held at the Shangri-La Beijing Hotel.

As noted, this will be the first time the IETF has met in China – and this announcement has not been without its share of controversy. Earlier during the negotiations with the hotel, the IAOC (the administrative arm of the IETF) asked the IETF committee for feedback on the venue and the terms under discussion. This set off a firestorm of discussion, as there was a clause in the hotel contract that allowed the hotel to terminate the proceedings if illegal content was discussed. The debate on the main IETF mailing list was extremely… um.. “vigorous” with all sorts of commentary around what constituted appropriate content, around “freedom of speech”, around censorship… and all the related topics. If you know anything about the IETF (or have been to an IETF meeting), you can appreciate the passion that this particular topic elicited.

In the end, the IAC reported that this specific clause was removed from the hotel contract:

During the course of contract negotiations with the hotel the community was asked via email lists and by survey about a specific provision in the contract. Your feedback guided us in our efforts. We are happy to report that the provision has been removed from the contract.

…

In response to concerns that the discussion of some IETF topics may violate the law, the IAOC has been assured by the Host that a normal IETF meeting can be legally held in China and that no pre-screening of material or monitoring of session content is required or will be done.

With that, the IAOC unanimously approved Beijing as the host of IETF 79.

Given that we have a Voxeo office in Beijing (which started with our Micromethod/SIPmethod team but has since expanded to include more folks working on all Voxeo products), we’re delighted that an IETF event will be happening there and look forward to having some of our folks attend.

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

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?)

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

For those watching IETF standards, the draft agenda is now out for the upcoming 76th meeting of the Internet Engineering Task Force from November 8th through 13th in Hiroshima, Japan. As usual, it will be a jam-packed week of activity. The IETF 76 host committee has a great web site up filled with info about the event (including the fact that if you need a visa, you had better start now!).

Sadly, due to some other events on my schedule, I don’t expect to be out there at IETF76. And, given the 13-hour difference from US Eastern time, I somehow don’t see me participating remotely. Ah, well, I’ll just have to catch up face-to-face with IETF 77 in March in Anaheim, California…

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

On Monday over on the Emerging Tech Talk video podcast, I posted a brief interview with SIPit coordinator Robert Sparks that I recorded at the SIPit 25 event held in September 2009 at the University of New Hampshire InterOperability Lab (IOL) in Durham, NH, USA.

In the interview, we covered questions such as: What is the SIPit test event all about? How does it make communications systems better? What do participants do at the event? How can companies get involved?

More information about SIPit can be found at http://www.sipit.net/
Robert Sparks has also posted a summary of the SIPit25 event at:
http://www.ietf.org/mail-archive/web/rai/current/msg00720.html

From a Voxeo perspective, I know that our test team gained some valuable insight into interoperabilty with products from other vendors. We’ll be incorporating what we learned into future versions of our product. Getting this type of real-time feedback is why the SIPit events are so powerful. We definitely hope that other vendors will join in to future SIPit sessions.

Meanwhile, here is Robert Sparks…

Technorati Tags: sip, sipit, ietf

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

As someone writing Internet-Drafts for submission to the IETF, collaborating with co-authors always involves some challenges. Do you send the txt or XML around to co-authors in an email? Do you put them on a website? Do you try to use a version control system? Mostly with my co-authors we wind up shipping docs around via email… but whose is the most authoritative? Who has the master?

To try to help a bit on my own end, I’m trying out using Github to post my files in a public git repository. For those wise in the ways of git, the repo is at:

http://github.com/danyork/internet-drafts-york

Those who don’t know what I’m talking about might want to check out the two git tutorial videos I did earlier this year (and yes, I still need to post part #3).

Now I’m not sure git is the ideal tool for this task. The problem with Internet-Drafts is that the file name changes between versions. So one version is:

draft-york-sipping-p-charge-info-05.xml

and then when I want to do some edits to the doc to submit the next version, it needs to be renamed:

draft-york-sipping-p-charge-info-06.xml

In order for only the most recent file to be in the repo, yet still have the history intact, what it seems I need to do is use the git mv command to move the file from one name to another. So it’s basically:

git mv filename1 filename2
git commit -a

Write your commit message, and then naturally push to Github so that it has the most recent. Now I need to do this mv before I start editing it.

I also haven’t started using this with any co-authors yet. Mostly right now I’ve been working through how I will personally use it. However, the good news is that with having all the files in a repo, I can easily do a diff against what I have and what a co-author has. By using Github, I also have a backup of all the files out “in the cloud”. And mostly, I can point people to a development version of a file before it’s been formally submitted to the IETF.

I’m still working through this process… it’s definitely still an experiment. Stay tuned as I write more about what I find out. (And if you are an I-D author and have any great comments about how you manage your Internet-Drafts, I’d enjoy hearing them, too.)

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