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 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.

This morning I submitted a new version -07 of P-Charge-Info. Not much changed in the draft. Primarily I updated the IPR language to use the language of the IETF Trust as of February 2009 and added a reference pointing to RFC 3968.

The P-Charge-Info draft has been rather delayed on its path to becoming an Informational RFC primarily because just as I was about to request “expert review” per the process in section 4.1 of RFC 3427, the SIP and SIPPING working groups decided to revisit RFC 3427 and restructure how changes are made to SIP in general.

The result has been “RFC 3427bis”, a.k.a. draft-peterson-rai-rfc3427bis and section 4 defines a new lighterweight process for registering SIP headers. (Well, it speaks of a “Designated Expert” process, but my criticism of the existing draft is that it doesn’t easily explain what someone has to do to register a new SIP header.) While this RFC3427bis draft has not been ratified as an RFC, the RAI area is proceeding as if it has been and has already replaced the SIP and SIPPING working groups with SIPCORE and DISPATCH.

At this point I’m done with P-Charge-Info in that I’ve incorporated all comments that people have had and all I am looking to do now is move it through the end of the process to an Informational RFC. I will be contacting the RAI Area Directors shortly to sort out exactly what the next step is to get this moving along. In my ideal world, I’d like to see this published by the end of this calendar year.

I do, though, still welcome comments, so if you have any please feel free to pass them along.

P.S. For info about why I originally wrote this draft, see “P-Charge-Info and incredible disconnect between PSTN billing and the new world of SIP

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

Long-time readers will know that I have a fascination with the ideas behind P2PSIP, which I explained once before in a post “P2PSIP and pushing voice down into local clouds”. While it has very little directly to do with my work here at Voxeo, I’ve continued to help a team of folks with the IETF who are working on an Internet-Draft providing an overview of the security concerns related to P2PSIP.

Given the upcoming IETF 75 meeting, I published an updated version of the Internet-Draft last week. It is available at:

http://tools.ietf.org/html/draft-matuszewski-p2psip-security-requirements

Those of you interested in SIP, P2P networks or security in general may find it of interest. Here’s the abstract:

This document provides a security overview and analysis for the Peer- to-Peer Session Initiation Protocol (P2PSIP) overlay network. It discusses security threats for the P2PSIP architecture and its components. It compares security difference between client/server (C/S) and P2P implementations of SIP, and then partitions the P2PSIP architecture into layers and analyzes the security issues in each layer and the security relationship among the layers.

My particular contribution in this revision was writing a new section on “Interconnection to other networks“. Many, if not most, P2PSIP networks will want to interconnect with the legacy PSTN or with other SIP networks. This section takes a look at what the security ramifications are and what an implementor of a P2PSIP network should consider.

Comments and feedback about this draft are of course welcome. At IETF75 in Stockholm I know that members of the author team will be asking the P2PSIP Working Group to accept this as a “working group document” (another step on the path to becoming a RFC) and there will undoubtedly be further revisions of the document.

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: sip, p2p, p2psip, security, ietf, standards

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 I worked late last week on a new revision of the P2PSIP security overview Internet-Draft of which I am a co-author, I wound up learning of a wonderful hosted tool provided by the IETF called “Idspell”:

http://tools.ietf.org/tools/idspell/idspell.pyht

All you do is upload a text version of your I-D and… ta da… it goes through and checks the spelling in your draft. What’s great about Idspell versus the standard spell-checker in any editor, is that it has been preloaded with IETF-specific info. On the IETF Tools page it says:

Idspell uses an IETF-specific wordlist built from the last 2 years’ published RFCs, surnames of recent I-D authors and some manually added words.

It’s just one of many tools that have been made available to help authors more easily create Internet-Drafts. Very useful!

P.S. For those curious to see the latest version of the P2PSIP security overview Internet-Draft, I’m trying an experiment in using Github as a repository for my I-Ds. You can find them there at http://github.com/danyork/internet-drafts-york/tree/master

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: IETF, standards, Internet-Drafts

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

What are the components of a “peer-to-peer (P2P)” network? What are the different types currently available? When does it make sense to consider using a P2P architecture?

Given the intense amount of interest in P2P networking these days, the Internet Architecture Board recently came out with a new Internet-Draft, draft-iab-p2p-archs, on “Peer-to-peer (P2P) Architectures” that aims to help provide answers to these types of questions. Here’s the introduction:

P2P (Peer-to-peer) systems have received a great deal of attention in the last few years. A large number of scientific publications investigate different aspects of P2P systems, several scientific conferences explicitly focus on P2P networking, and there is an IRTF (Internet Research Task Force) Research Group (RG) on P2P systems (the Peer-to-Peer RG). There are also several commercial and non- commercial applications that use P2P principles running on the Internet. Some of these P2P applications are among the most widely used applications on the Internet at present.

However, despite all the above, engineers designing systems or developing protocol specifications do not have a common understanding of P2P systems. More alarming is the fact that many people in the telecom and datacom industries believe that P2P is synonymous with illegal activity, such as the illegal exchange of content over the Internet or P2P botnets.

The goal of this document is to discuss the tradeoffs involved in deciding whether a particular application can be best designed and implemented using a P2P paradigm or a different model (e.g., a client-server paradigm). The document also aims to provide architectural guidelines to assist in making such decisions. This document provides engineers with a high-level understanding of what defines a P2P system, what types of P2P systems exist, the characteristics that can be expected from such systems, and what types of applications can be implemented using P2P technologies. Such understanding is essential in order to appreciate the tradeoffs referred to above. In addition, we stress the importance of the fact that P2P systems can be used to implement perfectly legitimate applications and business models by providing several examples throughout the document.

Given my own long-standing personal interest in P2P networks (some of which I’ve written about here), I was pleased to see this document come out. Anything that helps improve the overall understanding out there of P2P systems is, in my opinion, a good thing.

The draft is still undergoing some revisions (and I know the authors would welcome further comments) and I believe a new version will be coming out soon. The latest version should always be able to be found at:

http://tools.ietf.org/html/draft-iab-p2p-archs

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

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 I sit here reviewing papers for the upcoming W3C Biometrics Workshop, it occurs to me that I should give some background for this Workshop.

The two standards organizations I’ve had the most involvement with, IETF and W3C, have been adding voice biometrics to their standards in fits and starts for several years now.

MRCPv1, a widely-implemented protocol (API) for interacting with Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) engines, did not contain support for Speaker Identification and Verification (SIV), but one of its extensions did.

Portions of this extension made their way into MRCPv2, the standards-track successor to MRCPv1.

The W3C Voice Browser Working Group briefly considered some SIV markup for VoiceXML 2, but there wasn’t sufficient support at the time.

Now, the Working Group is reviewing SIV features for addition to VoiceXML 3. Although the feature set of a W3C specification is not truly set until the specification reaches the Recommendation Stage, this time there appears to be sufficient interest in adding SIV primitives to the language.

To get more information from the knowledgeable public, W3C is holding a workshop to “identify and prioritize directions for SIV standards work as a means of making SIV more useful in current and emerging markets. ” The workshop will be held in early March at SRI in Menlo Park, California.

Although the paper submission deadline has passed, if you were unaware of this workshop and are dying to attend, please email member-siv-submit@w3.org as described in the Call for Participation.

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

With IETF 73 coming up shortly in Minneapolis, those of us here in Voxeo were very busy last week getting our Internet-Drafts updated in time for Monday’s submission deadline. One of the major pieces of work was done by Dan Burnett with his new revision of the Media Resource Control Protocol Version 2 (MRCPv2) draft.

MRCP is actually a fascinating protocol to me (okay, admittedly, I’m a standards geek) in that it provides an open standard that allows a system to very easily interoperate with different “media processing resources” such as Automatic Speech Recognition (ASR) or Text-To-Speech (TTS) engines. This is how, for instance, our Prophecy product is able to easily use different ASR or TTS engines. In a very simplified view, it looks something like this:

where the “MRCP Client” is, in our case, Prophecy. Now the cool part about this is that if you need a specific ASR engine for a task, if you can find an “MRCP-compliant” engine it should be able to easily interoperate with Prophecy. Say, for instance, that you needed speech rec for a language we didn’t support, a special TTS engine or something like that.

Anyway, the new draft of MRCPv2 is out there and goes into this in an extraordinary amount of detail. If you do have any comments, by the way, Dan Burnett is open to hearing them (his email address is at the end of the draft).

P.S. If you’ve used our Realtime Debugger or our Prophecy Log Search feature inside of Evolution, you’ve no doubt seen a bunch of messages related to MRCP – this is all part of the communication between our main execution environment within Prophecy and the various ASR and TTS resources being used to execute your application.

Technorati Tags: MRCP, IETF, Standards, ASR, TTS, SIP

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 if we get to the point where we can truly “trust” the identity of the person calling us on the other end of a SIP connection, what will that look like to the end user? How will I know – easily – that I can trust that the “Caller ID” displayed on my IP phone is in fact who it says it is? Is there a “visual identifier” of some type that I could have on my IP phone (or softphone) that would clue me in? Kind of like the “lock” icon in web browsers that indicates a call is encrypted?

Those were the questions I was looking to address in a new Internet-Draft I submitted yesterday:

draft-york-sip-visual-identifier-trusted-identity-00

One of the things we focus on here at Voxeo is to ensure that the user experience is as simple and easy as possible. That’s why we rolled out our Designer tool a few years back. That’s why we spent a good amount of time looking to make Prophecy Log Search as simple to use as possible – and why we continue to improve it.

So in the discussions that have been going on within the IETF circles around the incredible need to nail down the ability to have “trusted identity” within communication based on SIP (which I wrote previously, one of the questions I’ve kept asking myself is “how will this appear to a regular end-user?” Based on some comments in the SIP mailing list the other day, I decided to write up this draft.

Feedback is welcome. I’ve already received the comments that I didn’t address the whole issue of PSTN interconnectivity, i.e. if it’s coming from a PSTN gateway, how do you deal with the fact that the Caller ID could have been spoofed on the PSTN side. I’m sure other comments will come in as well.

As I say in the draft, it’s not entirely clear to me that the IETF is the right place to have this discussion since ultimately it is about the user interface in vendor products… but at least it’s a place to start.

Technorati Tags: ietf, standards, sip, dan york, sip identity, identity

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