Archive for the ‘Skype’ Category

Skype releases source code for SILK super wideband audio codec – the details…

Thursday, March 11th, 2010

skypelogo-shadow.pngWant 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:

Jonathan Christensen's Presentation at eComm 2009
View more presentations from eCommConf.

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?

Want to learn how Voxeo can help unlock your communications and deliver a better customer experience? Please contact us!

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

Tags: , ,
Posted in Audio, IETF, Internet-Drafts, Skype, Standards, Wideband | 17 Comments »

Guest post: David Bryan responds on P2P, P2PSIP and Skype

Monday, October 26th, 2009

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.

Want to learn how Voxeo can help unlock your communications and deliver a better customer experience? Please contact us!

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

Tags: , , ,
Posted in IETF, P2P, SIP, Skype | 1 Comment »

Could Skype realistically replace its P2P algorithm with P2PSIP?

Monday, October 19th, 2009

skypelogo.jpgCould Skype realistically replace its proprietary peer-to-peer (P2P) algorithm with P2PSIP?

Over on his Skype Journal site, Phil Wolff shows another example of why I’ve always followed the mantra “Never put online, in any form, anything you don’t want to appear on the front page of a news site” when Phil shows what was obviously intended to be a private email about ideas of what to do with Skype. (This has all surfaced as part of Skype’s ongoing legal battles on a number of different fronts, which I’m not going to dive into here.)

Per Phil’s article, the idea was this:

- buy skype, replace p2p with SIP (standard-based, open, can interwork with other VoIP systems – like the Cisco phones)

What’s perhaps most interesting about Phil’s post, though, were the comments that started with Lee Dryburgh of eComm fame weighing in saying that it makes ZERO sense (technically) and then went on from there. Lee and Shidan Gouran then got into a bit of a discussion in the comments.

Leaving the personal jabs aside, it’s actually an interesting discussion to consider. (And knowing both Lee and Shidan, I’m sure that they actually agree on way more than they disagree on.)

WHAT IS P2PSIP?

Lee’s right that there’s a difference between “SIP” as a protocol and all the overlays, DHTs and everything else that goes with “P2P” protocols. To Lee’s points about the difference, though, that is precisely what the “P2PSIP” work happening within the P2PSIP Working Group of the IETF is addressing. For those who want to read the proposed P2PSIP protocol itself, the latest draft is here in two parts:

http://tools.ietf.org/html/draft-ietf-p2psip-base
http://tools.ietf.org/html/draft-ietf-p2psip-sip

The first draft defines a P2P protocol called “REsource LOcation And Discovery (RELOAD)”. The second draft explains how RELOAD can be used with SIP.

To Lee’s points, RELOAD is a separate protocol from “SIP”. Now, RELOAD does indeed use a Chord-based DHT… though, the best place to start is probably the Architecture section at the beginning to understand how the pieces fit together.

So what is being called “P2PSIP” within the IETF is more this:

P2PSIP = SIP + P2P-protocol

More info about all things related to P2PSIP can be found at a great site maintained by David Bryan, co-chair of the IETF P2PSIP Working Group: 

http://www.p2psip.org/

I’ve also written more about “P2PSIP” here on this blog, including this piece back in May 2008 about why I believe P2PSIP is important.

BUT COULD SKYPE REALLY USE P2PSIP?

Probably.

The question is really –

Could Skype swap out it’s proprietary P2P protocol for the P2P protocol proposed as part of P2PSIP?

That’s the larger issue. As Lee points out, SIP is “just” a signaling protocol for setting up communication sessions. The decentralized P2P nature of Skype is due to its proprietary P2P algorithm, not its session signaling.

That’s the key point, really – there are two different layers of communication going on here:

  1. networking between the endpoints (the P2P layer)
  2. call and chat signaling setup, modification, tear-down, etc.

The P2P layer is probably the hardest one to replace. The signaling layer is probably easier as there are any number of choices out there today, including SIP, XMPP and others.

Plus, as Shidan Gouran accurately points out, Skype’s current system is NOT entirely decentralized/P2P. It is much more of a hybrid system. There are centralized enrollment/authentication servers (as we learned in the multi-day outage a few years back), a centralized directory (although pieces of that could potentially be spread across the P2P overlay) and of course centralized PSTN interconnectivity.

Could all that be replaced with a different P2P protocol? Probably… although certainly not without a lot of work – and also the severe headaches of dealing with backward compatibility and getting the huge installed base of Skype users to upgrade to a new client.

Could that protocol be P2PSIP? Again, probably. The advantage would be that the SIP layer would give Skype interoperability with other systems, networks, devices, etc.

THE OTHER OPTION

I’d note, too, that the email Phil quotes says “replace p2p with SIP”. It does not say “replace p2p with p2psip”. There very well could be folks thinking of dumping the whole proprietary P2P protocol and dumping P2P in general and migrating to be a “standard” kind of SIP system like Gizmo (yes, which Skype has been rumored to be buying) or any of the other SIP-based consumer softphone services out there.

Sure, I’m sure they could technically do it. As an open standards guy, it would be great on one level in that it would help move us along toward the great big “interconnect” many of us so want to see. It would, though, require a much different architecture than what Skype has used so successfully today.

SO….

Will Skype replace their proprietary protocol with P2PSIP?

Ha… I haven’t a clue… nor does anyone else outside those walls. All we can do is have moments of technical amusement like this speculating on the possibility.

As I’ve noted before, Skype has been hiring in this year some great folks with lots of SIP experience… but… Skype is also a HUGE user of SIP on its backend for PSTN interconnectivity… plus they rolled out their Skype for SIP program this year…. so they have lots going on related to SIP.

We’ll see… all we can really say is that the time ahead will continue to be an interesting one for all things related to Skype…

Want to learn how Voxeo can help unlock your communications and deliver a better customer experience? Please contact us!

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

Posted in P2P, SIP, Skype | 18 Comments »

Skype imports some SIP DNA by hiring CounterPath CTO Jason Fischl

Tuesday, May 12th, 2009

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.

jf-tokyo2.jpgSo 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: , , , ,

Want to learn how Voxeo can help unlock your communications and deliver a better customer experience? Please contact us!

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

Tags: ,
Posted in SIP, Skype | 1 Comment »

Skype announces “Skype For SIP” to provide SIP connectivity to premise systems

Tuesday, March 24th, 2009

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: ,

Want to learn how Voxeo can help unlock your communications and deliver a better customer experience? Please contact us!

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

Tags: ,
Posted in SIP, Skype | 2 Comments »